🚀 go-pugleaf

In article <1993Jan25.163150.24449@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
> [proposed rule on lifetime of temporaries]
>     Temporaries are normally destroyed at the end of the statement
>     in which they are created.  The exception is that temporaries
>     created within a branch of a conditional (?:) operator are destroyed
>     when that branch is completed (and analogously for && and ||).

This seems like the most reasonable compromise.

>I would say that the committee was ready to compromise and decide on this
>except for one thing.  Nearly all of the discussion has assumed that we
>know what is a "temporary".  When asked directly regarding the formal
>argument x in the function

	class C { ...  C (const C&);  ... };
	void f(class C x) {   ... use x ...   }

>most people would say x is _not_ a temporary.

This is true, but that has nothing to do with your example below.  The
formal parameter x is a different thing entirely from the actual
parameter that is assigned to it.  The latter may be a temporary but
the former is not.

I changed the variable from x to w in your example to avoid confusion
(two different x's).

     String w, y;
     char *z;
     extern char *f(String x);
     z = f(w+y);

In this example there is a temporary that is the result of w+y.  This
temporary gets assigned to the formal parameter x of function f by means
of the copy constructor, at least conceptually.  But it could still be
considered a temporary in the sense of the rule above, meaning that it
lives until the semicolon.  Under this interpretation, we would have the
following action: temporary t is set to the result of w+y; this temporary
is passed to the x parameter of f with the copy constructor; at the end
of f that copy is destroyed, but t is still alive; the result is assigned
to z, and then t is destroyed.

The result is the same as if we replace the final statement above with

	{ String& t = w+y; z = f(t);}

Note that this has a cost: we cannot eliminate the copy constructor and
initialize x "in place" anymore.  This means that the fundamental cost
of passing an object by value has increased.


--
Joe Buck	jbuck@ohm.berkeley.edu