comp.lang.ada
 help / color / mirror / Atom feed
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Subject: Re: Assignment Overloading
Date: 14 Dec 88 18:05:29 GMT	[thread overview]
Message-ID: <3890@hubcap.UUCP> (raw)
In-Reply-To: 8812140455.AA16282@ajpo.sei.cmu.edu

From article <8812140455.AA16282@ajpo.sei.cmu.edu>, by TUFFS1@alcoa.com:
>   X := X + Y;    [-- generates an inaccessible temporary result...]
> 
> Unfortunately, this does not give in-place computation, since after the 
> assignment X will be "pointing" to a whole new structure, and the 
> previous structure will be inaccessible.  What we seem to need is a way 
> of "getting at" the thing which is the function result.  [...] 
>
> Comments, flames, problems?
> 
> Simon Tuffs
> Tuffs@Alcoa.Com

    I've thought about this problem too.  Probably the best way to
    handle it would be to define the parameter passing mechanism
    such that a function result ("anonymous", and thus not referencable
    elsewhere) will always be directly substituted for an "in" parameter,
    rather than being assigned or copied.

    Another idea I had along these lines is the more general question of
    "How can we handle the situation in which a temporary object whose
    sole purpose is to be passed once as an "in" parameter must be 
    1) needlessly assigned or copied during the parameter pass, and 
    2) explicitly destroyed afterward?".  The answer I came up with,
    which I don't recall ever seeing discussed in the literature, is
    "pass by handoff".  In a pass by handoff, you precede the expression
    to be handed off by a @, thus:

           PROCEDURE_CALL (@TEMPORARY_VARIABLE);

    Now what happens is that the object is directly substituted for the
    formal "in" parameter, and the temporary variable is left undefined.

    The problem is that the mechanism requires that all objects have
    "undefined" as a member of their carrier space, and my earlier
    suggestion that all objects should have "undefined" as an implicit
    member of their carrier space did not generate much enthusiasm.
   
    By the way, thanks for the idea of the Deallocate service!


                                        Bill Wolfe

                                wtwolfe@hubcap.clemson.edu
 

      reply	other threads:[~1988-12-14 18:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1988-12-06 13:05 Assignment Overloading TUFFS1
1988-12-14 18:05 ` William Thomas Wolfe,2847, [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox