Dave, The constructor could also instantiate objects that are then referred to by handles contained within the object. This was clearly not the intent of the shallow copy. So it seems that I can see reasons why we shouldn't call the constructor as well as reasons why we might want to when doing a shallow copy. I guess I am now leaning towards not calling the constructor, as is proposed in the mantis item. Neil Rich, Dave wrote On 04/12/06 12:32,: > Neil, > > 1. The current BNF for a class new does not allow arguments to be passed > when doing a shallow copy. That is why we thought the new method wasn't > supposed to be called. > > 2. There are handles to classes, events, virtual interfaces, and > covergroups. I would expect all of them to point to the original object > being copied when doing a shallow copy. > > When you do > > covergroup cg; ... endgroup > cg cg_inst = new; > > > What is stored in cg_inst? A handle to a covergroup instance. > > > Dave > > > > > > >>-----Original Message----- >>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > > Neil > >>Korpusik >>Sent: Wednesday, April 12, 2006 11:33 AM >>To: Ryan, Ray >>Cc: sv-ec@eda.org >>Subject: Re: [sv-ec] proposal for mantis #1382 - shallow copy >> >>Ray, >> >>My comments are embedded below. >> >>Neil >> >> >> >> >>> > ------------------------------------------------------------------------ > >>>Section 7.11 Assignment, renaming, and copying >>> >>>In 7.11, following the paragraph that begins: >>> >>> The last statement has *new* executing a second > > time, > >>>thus creating a new object p2, whose class properties are copied > > from > >>>p1. This is known as a /shallow copy/. ... >>> >>>ADD the new paragraph >>> >>> A /shallow copy/ executes in the following manner: >>> >>>1. An object of the class type being copied is allocated. > > This > >>>allocation shall not call the objects constructor or execute any >>>variable declaration initialization assignments. >> >>[NK] Calling the class constructor can have side affects that occur >>outside of the >>instance of the object being constructed. This includes triggering > > events, > >>assigning values to variables, etc. Do we really want to say that > > calling > >>the >>new method during a shallow copy will not actually call the new > > method? I > >>think >>that a lot of people would find this rather confusing. >> >>When the new method has arguments the values of those arguments may be >>used to >>assign values to class properties. These properties may then be used > > by > >>the new >>method to update variables outside of the class. >> >>It seems to me that the new method should be called as the first step > > of > >>the creation of an object that specifies a shallow copy. It may be >>possible >>for implementations to optimize this step such that a minimal number > > of > >>operations are performed. For example, in situations where the > > constructor > >>only sets the values of class properties, the call to new can be >>eliminated >>since those property values will be over-written when the shallow copy >>takes >>place. >> >>This implies that variable initialization assignments should also take >>place. >> >> >> >>>2. All class properties, including the internal states uses > > for > >>>randomization and coverage are copied to the new object. Object > > handles > >>>are copied, this includes the object handles for covergroup objects > > (See > >>>clause 18). The internal states for randomization include the RNG > > state, > >>>the 'constraint_mode' status of constraints, the 'rand_mode' status > > of > >>>random variables, and the cyclic state of randc variables (See > > clause > >>13). >> >>[NK] Don't handles only refer to class objects? This proposal is >>introducing >>the notion of a handle to a covergroup. I would expect each instance > > of > >>the class >>to have its own copy of any embedded covergoups. Using a shallow copy >>during the >>construction of the object shouldn't change that. >> >> >> >>>3. A handle to the newly created object is assigned to the >>>variable on the left-hand side. >>> >>> Note: A shallow copy does not create new coverage objects > > (covergroup > >>>instances). As a result, the properties of the new object are not >> >>covered. >> >>> >>> >>>MODIFY the example (following the paragraph) >>> >>> *class* A ; >>> >>> *integer* j = 5; >>> >>>*endclass* >>> >>>*class* B ; >>> >>> *integer* i = 1; >>> >>> A a = *new*; >>> >>>*endclass >>> >>>**class *C extend A ; >>> >>>* rand int *x; >>> >>>* constraint *cst1 { x < 10; } >>> >>>*endclass* >>> >>>*function* *integer* test; >>> >>> B b1 = *new*; // Create an object of class B >>> >>> B b2 = *new* b1; // Create an object that is a copy of b1 >>> >>> C c1 = new; // Create an object of class C >>> >>> A c2, c3; // Declare class variables (null value) >>> >>> b2.i = 10; // i is changed in b2, but not in b1 >>> >>> b2.a.j = 50; // change a.j, shared by both b1 and b2 >>> >>> test = b1.i; // test is set to 1 (b1.i has not changed) >>> >>> test = b1.a.j; // test is set to 50 (a.j has changed) >>> >>> c1.x = 3; >>> >>> c2 = c1; // c2 refers to the same object as c1 >>> >>> c3 = new c2; // Creates a shallow copy of c1 (including property > > x) > >>>*endfunction* >>> >>> >>> >> >>-- >>--------------------------------------------------------------------- >>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 Wed Apr 12 13:01:15 2006
This archive was generated by hypermail 2.1.8 : Wed Apr 12 2006 - 13:01:21 PDT