🚀 go-pugleaf

In article <4gfg21$iga@caesar.ultra.net> phalpern@truffle.ultranet.com
(Pablo Halpern) writes:

|> kanze@gabi.gabi-soft.fr (J. Kanze) wrote:

|> >In article <4eto87$9kf@hermes.synopsys.com> jbuck@Synopsys.COM (Joe
|> >Buck) writes:
|> >> 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.

|> Hmmm... I take it that you don't consider pass-by-value to be an
|> implicit copy? Perhaps you're right, but I don't really see where the
|> implicit vs. explicit question enters into this. I consider it an axiom
|> that if you assign "a = b" that you can then assume that "a == b" is
|> true unless a or b are volatile. If you write a copy constructor or
|> assignment operator such that this is NOT true, then you are asking for
|> trouble, IMHO. This leaves me with a delema wrt auto_ptr<> because,
|> while I like what it is trying to do, I don't like the idea of breaking
|> fundamental axioms in such a flagrant way. This could cause a ripple
|> effect. I'm not sure what kinds of compiler optimizations might not be
|> possible or even if certain semantics might become unpredicatable in
|> this case. Maybe I'm overstating the problem. Auto_ptr<> semantics seem
|> simple enough on the face of it and maybe this isn't a problem in
|> reality. (Programming, especially in C++, is not expected to be the same
|> as mathmatics, after all.)

You're not overstating anything.  You have precisely described the
dilemma concerning auto_ptr, and why there is so much discussion about
it.

In general, I agree with the concerning voiced about the changed
semantics of operator=.  In the case of auto_ptr, however, in all of the
cases where I think one would reasonably want to use it, the value on
the right hand side is either a temporary, or a value about to disappear
anyway.  So the changed semantics don't bother me too much.
-- 
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
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]