From 2201456861603727074
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,280ba96e37335d52
X-Google-Attributes: gidf78e5,public
From: clamage@Eng.Sun.COM (Steve Clamage)
Subject: Re: Inherent C++ problem??
Date: 1996/02/06
Message-ID: <4f8adk$fn6@engnews1.Eng.Sun.COM>#1/1
X-Deja-AN: 139029404
references: <199602060648.HAA19423@mail.pi.se>
x-original-date: 6 Feb 1996 19:33:08 GMT
organization: Sun Microsystems Inc.
x-auth: PGPMoose V1.1 PGP comp.std.c++
reply-to: clamage@Eng.Sun.COM
newsgroups: comp.std.c++
originator: austern@isolde.mti.sgi.com

In article HAA19423@mail.pi.se, william.mc@pi.se (William McIlhagga) writes:

>1) The standard says that an implementation *may* get rid of some copy
>constructors; it does not demand it. Thus the indeterminism lies in the fact
>that the programmer does not know whether this has happened to their code,
>unless the compiler is kind enough to say so (compilers are the strong
>silent type, and don't usually tell you anything about what they're thinking)

>2) Removing copy constructors is intended as an optimisation. But
>optimisations should never change the meaning of a program - that is, the
>program should produce the same results with and without the optimisation.
>Clearly, removing "irrelevant" copy constructors is a different kind of
>thing altogether. 

>I think this part of the standard is a little dangerous. I accept that
>removing copy constructors is a useful optimisation however (though I
>haven't seen any benchmarks to show how big a speedup you get - perhaps
>someone could post some to convince us all that it's worthwhile). There are
>a few things that might improve the situation:

>1) if an implemention removes a copy constructor, the standard should demand
>that it issues a warning message (if the user desires...). Though I guess
>most people will turn this warning off after a couple of hours, so maybe
>that's not so smart.

>2) the standard should include some specified way of switching off the
>removal of copy constructors. If it's in the standard then it's
>transportable, so no problems there. Perhaps some ugly #pragma or something?

The problem is not just that a copy constructor might be elided in code like
	T t = T(x); // T is some type
Whether the temp gets elided might depend on the optimization level that
was set or whether debugging is turned on.

The compiler is also allowed to create extra temps where convenient.

In addition, unless you are EXTREMELY knowledgeable about very fine
semantic details of C++, you will be unable to determine reliably where
temps must be created according to the language semantics. Even if you
have this deep knowledge, it takes a very careful analysis of even a
simple expression like
	x = a + b + c;
to determine where (if anywhere) temps must be created. It depends on
the parameter types of the functions called, which further depends on
the way overloaded function calls are resolved.

I really don't think you want to get messages about every temp that
was created and every optional temp that was omitted. I also don't think
you want to try to tell the compiler where it should and where it should
not omit unneeded temps.

Instead, the basic design rule is that program correctness should not
depend on exactly how many temps get created. Even with the compiler
options you are asking for, a program with such a dependence would be
unmaintainable.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]