I don't view this as a problem. > Should casting back into a particular object effect class-wide > static properties? Yes, it should. One must be very careful when choosing to use static properties. You have pointed out one case which needs to be considered. Yes, you end up changing the statics for all instances when restoring the state of an instance of that class. That is how statics work. Gordon Vreugdenhil wrote On 03/17/06 14:01,: > A static property is definitely non-constant but it is really > associated with the type, not the object. > > If, as stated in 22.3, the intent is: > > [Variable b can be used] to hold the bit pattern of a variable of [type > MyType] without loss of information. > > then we have a fundamental problem since if: > a) you don't include the statics then you don't have all the > information > b) you include the statics but then you can't "recover" the > state without impacting the state of every other object of > the type. > > Should casting back into a particular object effect class-wide > static properties? That seems to be problematic. > > Since the user can always write their own, I think that the > statics should be excluded by default so that reading back > into an object won't, by default, impact class static properties. > > Gord > > > > Neil Korpusik wrote: > > >>The stream should always contain all of the properties. >> >>It is true that all instances of the class share static properties, but I don't >>see that as being a good reason to exclude those properties from the stream. >>I believe that it was always our intent to include all of the properties >>in the stream. >> >>Users of classes don't think of a static property as being part of the type. >>The values of static properties can vary. They aren't constants. Anything >>that is part of a type has a constantness to it. >> >>Perhaps subclause 7.8 is not as clear as it should be. I could see how one >>might come away with the impression that a static property is fixed to a >>particular value. The intent is for a static property to be a shared property, >>not a constant valued property. >> >> >>Neil >> >> >> >>Rich, Dave wrote On 03/17/06 09:21,: >> >> >>>And here's a related issue that I will tack onto a proposal for mantis >>>1384. >>> >>>Should static members of class be part of the stream? The internal >>>discussion here was that they should not. A static member is part of the >>>type, not the instance. >>> >>>Dave >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] >>>>Sent: Tuesday, March 14, 2006 11:34 PM >>>>To: Neil.Korpusik@Sun.com; Rich, Dave >>>>Cc: sv-ec@eda.org >>>>Subject: RE: [sv-ec] Q: Should local or protected members of a class >>> >>>be >>> >>> >>> >>>>excluded from a bit stream cast. >>>> >>>>I tend to agree. I see no reason why the access granted to the >>> >>>streaming >>> >>> >>> >>>>operators should be any differently than for any other operator. >>>> >>>> Arturo >>>> >>>>-----Original Message----- >>>>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of >>> >>>Neil >>> >>> >>> >>>>Korpusik >>>>Sent: Tuesday, March 14, 2006 4:29 PM >>>>To: Rich, Dave >>>>Cc: sv-ec@eda.org >>>>Subject: Re: [sv-ec] Q: Should local or protected members of a class >>> >>>be >>> >>> >>> >>>>excluded from a bit stream cast. >>>> >>>>I agree with your position on this. >>>> >>>>Trying to access a protected or local property from outside the class >>>>should be illegal. Accessing a subset of the properties when using >>>><<, >> or a bitstream cast on a class handle is not appropriate. >>>>Instead, it should be considered an illegal attempt to access the >>>>local or protected properties. >>>> >>>> >>>>Neil >>>> >>>> >>>> >>>>Rich, Dave wrote On 03/14/06 16:14,: >>>> >>>> >>>> >>>>>I was hoping to gather some opinions on this. Without any other >>>> >>>>comment, >>>> >>>> >>>> >>>>>I will propose to make it illegal. >>>>> >>>>>Dave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Neil Korpusik [mailto:Neil.Korpusik@Sun.COM] >>>>>>Sent: Tuesday, March 14, 2006 1:44 PM >>>>>>To: Neil.Korpusik@Sun.COM >>>>>>Cc: Rich, Dave; sv-ec@eda.org >>>>>>Subject: Re: [sv-ec] Q: Should local or protected members of a class >>>>> >>>>>be >>>>> >>>>> >>>>> >>>>> >>>>>>excluded from a bit stream cast. >>>>>> >>>>>>Mantis 1384 has been opened for this issue. >>>>>> >>>>>>Neil >>>>>> >>>>>> >>>>>> >>>>>>Neil Korpusik wrote On 03/14/06 11:04,: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>8.17 Sreaming operators (pack/unpack) >>>>>>> >>>>>>>This sub-clause discusses the use of << and >> on class handles. >>>>> >>>>>There >>>>> >>>>> >>>>> >>>>> >>>>>>>doesn't appear to be any mention of local or protected properties. >>>>> >>>>>The >>>>> >>>>> >>>>> >>>>> >>>>>>>same issue you are raising for a bit-stream cast seems to also be >>>>>> >>>>>>relevant >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>to the streaming operators. >>>>>>> >>>>>>>Neil >>>>>>> >>>>>>> >>>>>>>Rich, Dave wrote On 03/14/06 07:15,: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>This raises a deeper issue. I thought the intent of >>> >>>local/protected >>> >>> >>> >>>>>was >>>>> >>>>> >>>>> >>>>> >>>>>>>>just linting. You should be able to remove the 'local' and >>>>> >>>>>'protected' >>>>> >>>>> >>>>> >>>>> >>>>>>>>keywords from code that previously compiled with no change in >>>>>>>>functionality. Therefore, bit-stream casts with local members >>> >>>should >>> >>> >>> >>>>>be >>>>> >>>>> >>>>> >>>>> >>>>>>>>illegal (unless you are bit streaming 'this'). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>The latter seems a bit harsh, but are there other places >>>>> >>>>>local/protected >>>>> >>>>> >>>>> >>>>> >>>>>>>>changes the semantics of an operator? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>> >>>>- >>>> >>>> >>>> >>>>>-- >>>>> >>>>> >>>>> >>>>> >>>>>>>>*From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On >>> >>>Behalf >>> >>> >>> >>>>>Of >>>>> >>>>> >>>>> >>>>> >>>>>>>>*Rich, Dave >>>>>>>>*Sent:* Monday, March 13, 2006 11:13 AM >>>>>>>>*To:* sv-ec@eda.org >>>>>>>>*Subject:* [sv-ec] Q: Should local or protected members of a class >>>>> >>>>>be >>>>> >>>>> >>>>> >>>>> >>>>>>>>excluded from a bit stream cast. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I think the answer should be yes, and this should be an erratum in >>>>> >>>>>the >>>>> >>>>> >>>>> >>>>> >>>>>>LRM. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>David Rich >>>>>>>>Verification Technologist >>>>>>>>Design Verification & Test Division >>>>>>>>Mentor Graphics Corporation >>>>>>>>dave_rich@mentor.com >>>>>>>>Office: 408 487-7206 >>>>>>>>Cell: 510 589-2625 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>-- >>>> >>>>>--------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>>>>Neil Korpusik Tel: 408-720-4852 >>>>>>Senior Staff Engineer Fax: 408-720-4850 >>>>>>Frontend Technologies - ASICs & Processors (FTAP) >>>>>>Sun Microsystems >>>>>>email: neil.korpusik@sun.com >>>> >>>>>--------------------------------------------------------------------- >>>>> >>>>> >>>>> >>>> >>>>-- >>>>--------------------------------------------------------------------- >>>>Neil Korpusik Tel: 408-720-4852 >>>>Senior Staff Engineer Fax: 408-720-4850 >>>>Frontend Technologies - ASICs & Processors (FTAP) >>>>Sun Microsystems >>>>email: neil.korpusik@sun.com >>>>--------------------------------------------------------------------- >>>> >>> >>> >>> > -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Senior Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------Received on Fri Mar 17 14:11:01 2006
This archive was generated by hypermail 2.1.8 : Fri Mar 17 2006 - 14:11:05 PST