RE: [sv-bc] Constant method calls

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Feb 07 2008 - 21:57:15 PST
Greg,

I don't think you can apply the next() method to an enum constant, only
to an enum variable.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Greg Jaxon
> Sent: Friday, February 08, 2008 6:45 AM
> To: Surya Pratik Saha
> Cc: Greg Jaxon; Steven Sharp; sarani@cal.interrasystems.com; 
> sv-bc@server.eda.org; sv-ec@server.eda.org
> Subject: Re: [sv-bc] Constant method calls
> 
> Surya,
> 
>    For enum { A=1, B, C }   A.next is always B,  B.next is always C.
>    I think the method is constant when applied to a constant 
> enum value.
>    Only some LRM wording and some implementation effort is needed to
>    make it so.  A compelling example would probably be needed 
> to persuade
>    the implementers on the committee.
> 
> Greg
> 
> 
> Surya Pratik Saha wrote:
> > 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.
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Feb 7 21:58:17 2008

This archive was generated by hypermail 2.1.8 : Thu Feb 07 2008 - 22:00:10 PST