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

Internet Message Format | 1992-08-20 | 2.8 KB

Path: sparky!uunet!mcsun!corton!seti!goudurix.inria.fr!edelson
From: [e-mail] (Daniel R. Edelson)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Keywords: temporaries,destruction,statements,block,early
Message-ID: <[e-mail]>
Date: 20 Aug 92 11:35:22 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: Daniel R. Edelson <[e-mail]>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France
Lines: 54


I'm not an expert on this issue, and so will just make one
quick point and then shut up.

In article <[e-mail]>, [e-mail] (Andrew Koenig) writes:
|> In article <[e-mail]> [e-mail] (Michael Hoennig) writes:
|>
|>     3. I have heard comments from users who really want temporaries
|>        cleaned up early if possible.  Typically they are using linear
|>        algrbra packages and write things like this:
|>
|>         Matrix D = A * B * C;
|>
|>        and do not want the intermediate result A * B to hang around
|>        until the end of the block.  Of course they can't enclose this
|>        in braces because then that would tear down D as well.  Moreover,
|>
|>         Matrix D;
|>         {
|>             D = A * B * C;
|>         }
|>
|>        in addition to being ungainly, substitutes assignment for
|>        initialization.  This can be significantly slower in some
|>        implementations.

It seems as though there is a tension between early destruction and
late destruction. The numerical scientists prefer early destruction
because their temporaries are very large and consume substantial
resources. Some others advocate late destruction because that
reduces the likelihood of dangling references.

My only observation is that correctness may be more important
than efficiency. Though early destruction may make some programs
run faster, will it introduce a disproportionate number of errors?

Also, what language will the Standard use to specify this. Assume
that the Standard defines when temporaries are destroyed. My fear
is that it will become 'undefined behavior' to hold a reference to
a temporary beyond the point where the temporary may have been
destroyed. Undefined behavior means that the programmer is wrong
but the compiler need not say anything. Thus, this can lead to
insiduous bugs that only appear under certain compilers, or
perhaps only with optimization enabled, etc.

Mere Mortals (tm) should be able to understand why their C++
program is or is not legal, without having to pester their
local guru every 15 minutes. (You can tell that my prime
consideration is not job security.)

|>                 --Andrew Koenig
|>                   [e-mail]

[e-mail]