Subject: Re: [sv-ec] Pass by reference
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Sat Feb 22 2003 - 22:16:29 PST
On Fri, 21 Feb 2003, Arturo Salz wrote:
> 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
You could treat passing by input/inout/output as the same as using
the copy constructor and use ref for creating a new reference, C++
does more or less that with <class> as an argument or return vs
<class> *.
Kev.
>
> ----- 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
> >
> >
>
>
>
>
-- mailto:Kevin.Cameron@nsc.com http://www-galaxy.nsc.com/~dkc/
This archive was generated by hypermail 2b28 : Sat Feb 22 2003 - 22:17:36 PST