🚀 go-pugleaf

In article <01BAEFD6.AD7E8620@dino.int.com> Eugene Lazutkin
<eugene@int.com> writes:

|> Why do I use wrappers?  Just small example: vector< auto_ptr< T > > 
|> (or list< auto_ptr< T > >).  I f you tried it, you'd discover that STL 
|> (I use ObjectSpace's implementation) uses copy-ctor with a const parameter 
|> and auto_ptr doesn't define it.

|> BTW, how come that auto_ptr from Standard C++ Library is incompatible with
|> vector<>, list<> and other STL containers from the same source? Or maybe I
|> have incorrect implementation?

And just when I thought I'd found a solution to the auto_ptr
problem:-).

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.  Even supposing that
STL and the language could handle it, what would be the meaning of:

	vector< auto_ptr< T > >
	                    v( 10 , auto_ptr< T >( new T ) ) ;

Certainly not what it would seem to be.

A possible solution would be to have two functions everywhere where
the STL requires a fill object.  (The current version has one
function, with a default parameter T() as fill.)  The version without
the fill object parameter would use the default constructor, rather
than copy.  Obviously, this is only interesting if the implementation
only instantiates functions that are actually used.  (I believe that
this is supposed to be the case, although I know that many
implementations do not do this.)

This still leaves a problem with the internal functions, such as
reserve, which may copy the data.  While not a problem for auto_ptr
(since they are copying non-const lvalues), it may be a problem for
other classes.
--
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, 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.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

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

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

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 
]

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