🚀 go-pugleaf

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.

Any definition of auto_ptr's copy constructor that doesn't follow these
rules is broken, I'm afraid.  The problem is with auto_ptr, not with
copy constructors or the STL.

-- 
-- Joe Buck 	<jbuck@synopsys.com>	(not speaking for Synopsys, Inc)

Work for something because it is good,
not just because it stands a chance to succeed.	   -- Vaclav Havel
---
[ 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. ]