NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13046

Internet Message Format | 1992-08-29 | 1.6 KB

Path: sparky!uunet!cs.utexas.edu!usc!rpi!uwm.edu!linac!att!att!allegra!alice!ark
From: [e-mail] (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Message-ID: <[e-mail]>
Date: 29 Aug 92 13:10:17 GMT
Article-I.D.: alice.23585
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] ()
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 21

In article <[e-mail]> [e-mail] (Frank Adams) writes:

> I don't claim to have a complete solution to the problem.  However, for the
> specific case   c ? a+b : a   where a+b creates a temporary, I would be
> tempted (as a compiler writer) to always return a temporary: a+b if c is
> true, and a copy of a otherwise.  This solves the problem of not knowing
> whether a temporary has been created.

I'm afraid it doesn't solve the problem.  For example, suppose `a' is of type
const char*, `b' is of type String, and String has one of those problematic
conversions to const char*.  Now, let's modify your example a tiny bit and
look at c?(const char*)(a+b):a.

This expression always returns a value of type const char*, but that's not
where the problem likes: the problem is in the temporary of type String
yielded by the subexpression a+b.  The value of (const char*)(a+b) is valid
only so long as that temporary stays around, so any games you play with
the const char* values themselves won't affect that.
--
                --Andrew Koenig
                  [e-mail]