🚀 go-pugleaf

In article <01BAE8B0.C408A920@dino.int.com> Eugene Lazutkin
<eugene@int.com> writes:

|> > Well, a typical optimisation here would be to construct the temporary
|> > inside op+ directly into the return value slot. The construction of 'c'
|> > would likely pass the address of 'c' as the return value slot. Thus, with
|> > suitable inlining, it becomes very efficient.

|> > And the current wording of the draft allows such optimisations --
|> > effectively arbitrary copy constructor invocations can be eliminated if
|> > either the copy or the original is never used again (as in this example).

|> This is exactly the kind of optimization that one would be expecting but it cannot
|> possibly work, at least not with the non-inline copy constructors:

It can, because the standard says it can.  The standard explicitly
gives the implementation the right *not* to call the copy constructor
in certain well-defined cases.  This is one of them.  (Note that there
still must be an accessible copy constructor.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]