🚀 go-pugleaf

In article <4eto87$9kf@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
Buck) writes:

> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
> >In fact, this is a weakness in the STL definition (IMHO).  STL
> >containers require *real* copy constructors, that actually copy.  For
> >something like auto_ptr, this is not reasonable.
> 
> The *language*, not just STL, requires copy constructors that actually
> copy.  The language automatically uses the copy constructor whenever it
> needs to make a copy.  The copy constructor is used to return objects from
> functions and to pass them in by value.  This usaga assumes that you get
> an actual copy.  Copy constructors can be optimized away in certain
> circumstances.  Again, this optimization works based on the assumption
> that a copy constructor does a copy, so you can avoid the copy by
> constructing the object in the right place.  It also means that having a
> side effect in the copy constructor (other than something that preserves
> copy semantics, like reference counting and such) is going to break
> things.

In all cases where the language (outside of the library) does an
implicite copy, the object being copied is destructed immediately after,
before the user can use it for anything else.  So a `copy' that in fact
`moves' will still work.

This is also the case in STL when it resizes a vector, for example.

In fact, in the particular example, I don't think that there is a real
problem either.  The user asked for something that the language
(including library) simply doesn't support; he wanted a vector of 10
auto_ptr's all pointing to the same object.  This is a contradiction.
It would be nice if this were made to require a diagnostic, but I don't
see how it would be possible.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]