Subject: RE: [sv-ec] Pass by reference
From: Neil Korpusik (Neil.Korpusik@eng.sun.com)
Date: Fri Feb 21 2003 - 17:55:55 PST
Hi David, Arturo,
The changes in CH-111 look much better than what we have now...
These changes work for me.
You may also want to check with Francoise, she and Arturo had a
couple of different similar threads going (note that there was a typo in one
thread header - it was referring to 10.5.3 when it meant to
refer to 10.5.2).
http://www.eda.org/sv-ec/hm/0755.html
http://www.eda.org/sv-ec/hm/0799.html
Thanks,
Neil
> From: "David W. Smith" <david.smith@synopsys.com>
> To: "'Neil Korpusik'" <Neil.Korpusik@eng.sun.com>, <sv-ec@eda.org>
> Subject: RE: [sv-ec] Pass by reference
> Date: Fri, 21 Feb 2003 17:23:37 -0800
> MIME-Version: 1.0
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id h1M1NQpT020332
>
> 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
>
> -----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 - 17:59:03 PST