|feature wanted: detect missing 'const' firstname.lastname@example.org (1994-03-16)|
|Re: feature wanted: detect missing 'const' email@example.com (1994-03-23)|
|Alternatives to const. firstname.lastname@example.org (1994-03-24)|
|Re: Alternatives to const. email@example.com (1994-03-25)|
|Re: Alternatives to const. firstname.lastname@example.org (1994-03-28)|
|From:||email@example.com (Michael Spertus)|
|Organization:||Dept. of Mathematics|
|Date:||Thu, 24 Mar 1994 14:37:57 GMT|
We are playing with the following. All parameters are declared in, out or
inout. They may be optionally be live and bare.
'in' means a copy of the caller's value is created for passing. This may
be optimized to a pointer but the user must see the callee's value as an
effective copy. This means you can pass anything that may be cast to the
'out' means a fresh copy of the value is created with default values. On
normal exit the parm is copied to the caller's side and any necessary
casts are done. On what we call failure or non local exit the out parm is
discarded. As with 'in' this may be optimized to a pointer where it is
'inout' means the parm is initialized by in rules and returned to the
caller by out rules. Thus casts must exist in both directions between the
caller's variable and the callee's type.
'live' is an optional parm descriptor. This is implemented as pointer. The
callee sees the caller's value live, if the value changes independently
the callee sees it. Thus the callee's type must be a subtype of the
'bare' is an optional parm descriptor which may be applied to any
variable. It means the user of this variable sees the implementation as
well as the interface. The callee's parm must be of a type whose
implementation as well as interface subclasses the caller's variable. Thus
the function decides when it needs to see implementation. This minimizes
violation of encapsulation.
Return to the
Search the comp.compilers archives again.