🚀 go-pugleaf

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.)

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.
---
[ To submit articles: Try just posting with your newsreader.  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 
]