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

Internet Message Format | 1992-08-20 | 4.9 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
Message-ID: <[e-mail]>
Date: 21 Aug 92 08:57:14 GMT
References: <[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: 94

In article <[e-mail]>, [e-mail] (Thomas M. Breuel) writes:
|> In article <[e-mail]> [e-mail] (Andrew Koenig) writes:
|>
|>    Destruction at end of block is far from a hopeless approach, but I
|>    think it loses on balance.  Indeed, there's something to be said for
|>    almost every approach, which is why this is a knotty problem.
|>
|> Let me put in another vote for leaving things the way they are.

Please, no. Nobody is happy with things the way they are now.

|> People want temporaries to live longer so that they can write
|> certain expression that involve returning pointers or references
|> to (the contents of) temporaries.
|>
|> However, delaying the destruction of temporaries (say, to the end of
|> an expression) fixes nothing. It makes a slightly larger set of
|> programs acceptable, but you still have to know in detail whether some
|> object has been derived in one way or another from a temporary. For
|> example, "char *p = s+t;" still leaves "p" undefined (if s and t are
|> Strings).

It depends, maybe end of expression isn't long enough. Maybe end of
block isn't even long enough.

|> The price you pay is that of making another set of programs use
|> (sometimes considerably) more memory. This is important in particular
|> for scientific applications, which can use many large temporaries
|> during a single expression. Such expressions (usually already tricky
|> the way they are) would be nearly impossible to rewrite by hand in
|> order to minimize memory use.

A previous poster mentioned quality of implementation.
I couldn't agree more. Scientific computation is a problem
for C++ operator overloading. Are we even certain that destroying
temporaries immediately makes C++ suitable for scientific
computation? At the the Usenix C++ conference advanced topics
workshop, we saw a presentation by a person from Boeing (I'm sorry,
my material is at home and I don't remember his name) who pointed
out some of the difficulties with scientific computations. One problem
is using the chaining capability of a cray.

Assume you have a matrix expression like
    D =  A * B + C;
Assume further that the compiler figures out how to vectorize
the multiplication. The next step is to chain the multiplication
to the addition. But this is very difficult because the functions
that implement the overloaded operators hide the fact that the loops
chain.

The point is, scientific computing is difficult. What are the
ramifications of dictating that temporaries get destroyed
very quickly. Does that suffice to make C++ acceptable in
numerical computing? Does that, on the other hand, make C++
a more difficult language for the general user?

I think the programming language should be a general one.
There can be a lot of room for high-quality implementations
and optimizations.

|> Maybe the ANSI C++ committee will accept this change.  I think it
|> would be a big mistake. I'm generally for features that make life
|> easier for the programmer, but the price for this one is simply too
|> high.

You may be right, but you haven't convinced me.
Suppose the committee embraces the semantics of late
destruction but permits 'as-if' early destruction. That is,
the compiler can destroy them early if doing so doesn't change
the meaning of the program. In general, it's probably impossible
to figure this out. But there may be cases in which it's possible.

|> You can avoid unexpected behavior involving temporaries by programming
|> defensively. In particular, this means: do _not_ return a reference or
|> pointer to an explicit or implicit argument or its contents (*this,
|> call-by-value, call-by-reference). Furthermore, do _not_ define cast
|> operators to pointer types in your classes (instead, make them normal
|> member functions that you have to call explicitly).

Then how do you every use smart pointers?
Kiss reference counting goodbye, or else we all will be
using accessors, not necessarily a bad thing.

|>                     Thomas.

In the best of all possible worlds, we would have the semantics
of late destruction with the efficiency of early destruction.
E.g., the compiler destroys temporaries upon return from the
enclosing function, except when it can prove that destroying them
earlier does not change the semantics of the program, excepting
side-effects in the destructor, which are permitted to change
the semantics of the program

[e-mail]