Subject: Re: [sv-ec] Pass by reference
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Fri Feb 21 2003 - 18:56:46 PST
Kevin,
That's precisely why the new clarifications where added to the LRM.
To create a copy of a class, you need to use the "copy constructor":
copy = new object;
Passing the handle, regardless of the direction doesn't create a copy.
Arturo
----- Original Message -----
From: "Kevin Cameron" <sv-xx@grfx.com>
To: <sv-ec@eda.org>
Cc: <Neil.Korpusik@eng.sun.com>; <david.smith@synopsys.COM>
Sent: Friday, February 21, 2003 6:33 PM
Subject: RE: [sv-ec] Pass by reference
> From: "David W. Smith" <david.smith@Synopsys.COM>
>
> Hi Neil,
> After some thought Arturo agreed that the handling of object handles when
> passed by reference needed some clarification. Can you take a look at CH-111
> (http://www.eda.org/sv-ec/CH111.html) and see if that works for you?
>
> Regards
> David
I would have thought that the desired semantics for input/output/inout would
be to copy the class contents rather than to just duplicate the handle, and
passing a class by reference seems to be creating a reference to a reference
(aka handle) - shouldn't that be the one that duplicates the handle?
Regards,
Kev.
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Neil
> Korpusik
> Sent: Thursday, February 13, 2003 1:51 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] Pass by reference
>
>
> Section 10.5.2, "Pass by reference", needs more explanation.
>
> The semantics for the various data types needs to be explained in more
> detail. I have tried to summarize my current understanding below for a
> couple of data types. This is the level of detail we should have in the LRM.
>
> unpacked arrays - a reference is passed as opposed to the contents of the
> array
> - modifications made to the array contents by the callee
> are
> visible to the caller.
> - the memory referenced can't be changed by the callee. In
> other words the same unpacked array will be used by the
> caller although the contents of that array may have been
> modified by the callee.
>
> object handles - a reference to the handle is passed.
> - the callee can modify the state of the referenced object
> (this is true no matter what "direction" has been
> specified).
> - the callee can modify the handle such that it now refers
> to
> a different object. This change is reflected in the
> caller.
> The object handle in the caller now refers to this new
> object.
>
> It appears that a 'ref' parameter behaves like an 'inout' parameter except
> for the fact that the contents of the data item aren't copied into the
> subroutine when using 'ref'. From a user perspective there doesn't appear to
> be any difference between an inout object handle and a ref object handle.
>
>
>
> Section 3.12, second paragraph, last sentence says, "Classes can also be
> passed around by reference via handles, adding a safe-pointer capability".
>
> This could be misconstrued to imply that object handles can only be passed
> to a subroutine when using 'ref' parameters. This is not the case. An object
> handle can be declared to be: input, output, inout or ref.
>
>
>
> Section 10.3 and 10.2
>
> We may need to get clarification from the BC committee on "output". Does
> this imply that a parameter passed to a subroutine using the "output"
> directionality has an undefined value upon entry to that subroutine?
>
>
> Neil
>
>
This archive was generated by hypermail 2b28 : Fri Feb 21 2003 - 18:55:02 PST