NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/std/cplus/2134

Text File | 1993-01-28 | 2.6 KB | 65 lines

Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!sdd.hp.com!saimiri.primate.wisc.edu!ames!agate!forney.berkeley.edu!jbuck
From: [e-mail] (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: Question about temporaries
Date: 27 Jan 1993 20:11:19 GMT
Organization: U. C. Berkeley
Lines: 53
Message-ID: <1k6q97$[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: forney.berkeley.edu

In article <[e-mail]> [e-mail] (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    [e-mail]