From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: destruction of temporaries
Date: 28 Aug 92 23:09:33 GMT
Article-I.D.: arolla.TMB.92Aug28190933
	<1992Aug25.182538.9117@microsoft.com>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: jimad@microsoft.com's message of 25 Aug 92 18:25:38 GMT

In article <1992Aug25.182538.9117@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

   I suggest that something like the following set of rules would in practice
   allow compiler implementations such that all existing conforming
   compiler/program pairs could continue to work:

   Rules in order of precedence:

   1) Lifetimes of unnamed temporaries never exceed their surrounding blocks,
     including the implied rewriting blocks of loops and conditionals.

   2) Named temporaries live to the end of their name's surrounding block.

   3) Temporaries must live until after their last access or end of block --
   whichever comes first.

   4) Compilers are allowed to destroy temporaries anytime in any order after
   their last access.

   [...]

   Niave implementations can simply wait to the end of block [where "block"
   includes the implied rewriting rules of loops and conditions].  Optimizing
   compilers are free to reclaim objects as soon as they are done being used.
   In some cases, this may be very hard for optimizing compilers to determine --
   in which case they are free to fall back on the naive scheme.  In practice,
   in many cases an optimizing compiler can simply determine last access,
   and can optimize lifetimes well.

If any function that is not visible to the compiler ever gets its
hands on the temporary, the temporary can't be deallocated at the end
of the block, since that function might have put a pointer to the
temporary somewhere. That means that the _only_ cases in which a
compiler might be able to optimize temporaries are cases in which all
the functions involving the temporaries are defined in the same
compilation unit, and of those cases, it will still not be able to
optimize most.

   Under these rules the only difference between named objects and unnamed
   objects is the destruction of named objects *must* occur at end of block,
   whereas for unnamed objects destruction can occur earlier.

Under your rules, for all practical purposes, there is no difference
between named objects and unnamed objects. You might as well simply
clearly state that unnamed temporaries live until the end of the
block. That way, nobody would have any illusions.

   The above rules shift the burden of temporaries to optimizing compilers.

No, it shifts the burden of temporaries to optimizing users: it means
that the user, for all practical purposes, could not use large
temporaries anymore, since he could pretty much expect that they all
accumulate until the end of the block.

I don't understand all this hoopla about temporaries. Yes, I myself
strongly dislike the fact that automatic variables and temporary
objects have dynamic extent in C++ (i.e., that pointers to them become
invalid).  But that problem is not going to be fixed by making those
objects live just a little longer. In fact, for all practical
purposes, the problem simply isn't fixable within C++. At best, you
can avoid it by using special coding conventions, by using GC and heap
allocated objects, or by using a different language. I have used all
three methods, depending on the particular constraints on my current
project.

					Thomas.
Newsgroups: comp.lang.c++