Hi Gordon, 'next' method is not constant because the value of 'next' method depends on the no. of call of that method. And this no. of call is not elaboration time constant. Is it not correct? Regards Surya -------- Original Message -------- Subject: Re:[sv-bc] Constant method calls From: Greg Jaxon <Greg.Jaxon@synopsys.com> To: Surya Pratik Saha <spsaha@cal.interrasystems.com> Cc: Steven Sharp <sharp@cadence.com>, sarani@cal.interrasystems.com Date: Thursday, February 07, 2008 10:46:56 PM > Surya, > > I concur with Steven's reading of the LRM, but as he hinted, the next > method when applied to a constant enum returns a deterministic result and > has no side-effects. I don't understand why you'd say it isn't "constant", > except that the LRM currently makes no accommodation for these methods in > the rules about constant expressions. > > Greg > > Surya Pratik Saha wrote: > >> Hi Steven, >> Is 'next' method call also allowed? I think no, though the method is >> called on a constant object. Because return value of 'next' is not at >> all constant. I think LRM should provide the list of method can be >> applied in const_expression context to avoid any confusion instead of >> leaving for the vendor tool. >> >> Regards >> Surya >> >> >> >> -------- Original Message -------- >> Subject: Re:[sv-bc] Constant method calls >> From: Steven Sharp <sharp@cadence.com> >> To: sv-bc@eda-stds.org, sarani@cal.interrasystems.com >> Date: Tuesday, February 05, 2008 11:36:44 PM >> >>>> From: Sarani Roy <sarani@cal.interrasystems.com> >>>> >>>> >>> >>> >>>> Since according to LRM "An enumerated type declares a set of integral >>>> named constants." >>>> It is not clear to me why we cannot use atleast first() , last() and >>>> num() >>>> enum methods as constant function call. >>>> As pointed out by Gord all the normal rules regarding constant >>>> function behavior would apply to >>>> to these function calls. >>>> >>>> >>> While I don't think that there is a technical problem with allowing these >>> to be constant functions, I agree with Brad Pierce that the current LRM >>> text does not allow them. >>> >>> Steven Sharp >>> sharp@cadence.com >>> >>> >>> >>> >> >> >> >> > > > > > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 7 20:15:04 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 07 2008 - 20:17:00 PST