Steven, > This came up here not too long ago, and I had not gotten around to > bringing it up to the committee. Thanks for the response. Since you've already given some serious thought to this, it's perhaps better for you to raise a Mantis item for it - but I'm happy to do it if you prefer. > My interpretation of the LRM was that it does not say that > constraint_mode() is virtual, so it isn't, even though > that doesn't make much sense. The LRM should probably > be modified to change that. I take your point, but it's not that simple. In the case that I was considering, constraint_mode() is not truly a method of the *class*, but rather a pseudo-method of the *constraint*. However, I suppose constraints work much more like data members of the class than like virtual methods, so your interpretation is still probably right. If so, then at least one simulator is broken, but it's the only one that gives desirable behaviour :-) I guess I'm not too worried about it anyway. constraint_mode() is an ugly thing to shoe-horn into any reasonable methodology; if you need it, you should have thought about putting appropriate control values and implication constraints into your class. > Regarding your supplementary question: Executing constraint_mode() at > simulation time to turn off a constraint does not make the constraint > name disappear. It definitely does not make it disappear back during > compilation, when names were resolved. So no, I don't think that the > base-class constraint would apply if the same-named derived-class > constraint is turned off. OK. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 Email: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat May 24 01:02:07 2008
This archive was generated by hypermail 2.1.8 : Sat May 24 2008 - 01:02:49 PDT