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
prev parent 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