NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12431

Internet Message Format | 1992-08-17 | 1.8 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!masscomp!peora!tarpit!fang!att!allegra!alice!ark
From: [e-mail] (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Message-ID: <[e-mail]>
Date: 17 Aug 92 12:24:36 GMT
Article-I.D.: alice.23466
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 38

In article <[e-mail]> [e-mail] writes:

> IMO temporaries should survive until end of statement.

This treatment has two significant disadvantages:

    1. If I break a statement up into several, it may
       quietly change its meaning.  Thus, for example, if
       String::operator const char*() exists, and s and t are
       of class String, then

        printf("%s\n", (const char*)(s+t));

       might work but

        const char* r = s + t;
        printf("%s\n", r);

       might not.

    2. It is a real pain to implement for statements that
       generate temporaries inside conditionals.  Thus, for
       example, in x>0?f(p+q):r, if p+q generates a temporary,
       and it was necessary to wait until the end of the statement
       to destroy it, it would also be necessary to remember which
       branch of the ?: was taken to decide whether or not to
       destroy it.  There are cases where this can add substantially
       to execution time.  Moreover, it greately complicates the
       implementation of exception handling, because it makes it
       impossible to have a static map from program counter value
       to offsets of statics to destroy.

For these reasons, I think a shorter lifetime than end of statement
is appropriate for temporaries.  Whether the committee will go that
way, however, remains to be seen.
--
                --Andrew Koenig
                  [e-mail]