🚀 go-pugleaf

In article <C1DtoB.FJ3@fiu.edu>, feathers@serss0 (Michael Feathers) writes:
> 
> Has the ANSI committee done any more work of the lifetime of temporaries?
> I'm very curious about this aspect of the emerging standard.

At the Boston meeting last November, some straw votes were taken to get
the sense of the committee of the whole.  IMO there was a clear leader
among the possibilities which seemed viable at the time.  Unfortunately
no prize was awarded. :-)  38 voted that the following was acceptable,
and none voted that it was unacceptable.

     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 ||).

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.  On the other hand, a very
popular implementation of C++ gives x the same extended lifetime as a
temporary.  Also, more than one example presented in favor of long-lived 
temporaries has actually needed long-lived formal arguments!  If I recall
correctly, an example was
     String x, y;
     char *z;
     extern char *f(String);
     z = f(x+y);
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

feathers@serss0 (Michael Feathers) writes:


>Has the ANSI committee done any more work of the lifetime of temporaries?
>I'm very curious about this aspect of the emerging standard.

It is still under discussion and has not yet been resolved.  I expect
that it will be resolved this year.

It is a hard problem, with excellent arguments both in favor of and
against all solutions proposed so far.

Once it has been resolved, it may take a while for existing
implementations to catch up to any needed changes.  So the best
advice so far is still to avoid dependencies in your code on how
long a temporary will live.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com

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