Christopher Eltschka wrote in message
<35D038F3.7D00606D@physik.tu-muenchen.de>...
>> > vector< auto_ptr<T> > would be a very useful construct to implement an

...
>> But auto_ptr as it was designed is totally unsuitable for putting inside
any
>> STL container class.
>
>Well, you can also see it the other way round:
>The STL container classes as they are designed are totally unsuitable
>for containing auto_ptrs (or anything else which supports "move-copy"
>rather than real copy.
>Now what Maarten explained is that most container operations don't
>need that restriction, as do many algorithms. So it would have been
>possible to distinguish between "moving" and "cloning" operations and
>algorithms, and relax the requirements for the "moving" operations
>to a non-const copy constructor. This would allow to put auto_ptrs
>into STL containers, and to use certain non-cloning algorithms on them.
>
>BTW, I'm wondering if an implementation which offered that could
>be conforming (that is, is a conforming implementation allowed to
>accept vector< auto_ptr<T> >?)


This problem I met during working on my project. When I realized that
auto_ptr does not support multiple ownership, I did my class AutoPtr, which
uses a reference counter. I'd like to discuss with people its advantages /
disadvantages and I'm ready to provide the source code of my class. I
understand that it's off-topic here, so may be let's do it on comp.prog.c++,
or by e-mail? If anybody is interested, answer me here or email to
skiba@macs.biu.ac.il




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Skiba<skiba@macs.biu.ac.il> wrote:
>Christopher Eltschka wrote:
>>> > vector< auto_ptr<T> > would be a very useful construct ...
>>> But auto_ptr as it was designed is totally unsuitable for putting
>>> inside any STL container class.
>>
>>Well, you can also see it the other way round:
>>The STL container classes as they are designed are totally unsuitable
>>for containing auto_ptrs (or anything else which supports "move-copy"
>>rather than real copy.
>>
>>BTW, I'm wondering if an implementation which offered that could
>>be conforming (that is, is a conforming implementation allowed to
>>accept vector< auto_ptr<T> >?)

Of course.  The effect of putting an auto_ptr<> in a container is
undefined by the standard.  Any implementation is free to provide
a definition, and the code would be portable among all implementations
which happen to provide the *same* definition.

>When I realized that
>auto_ptr does not support multiple ownership, I did my class AutoPtr, which
>uses a reference counter.

If you write a class with different semantics than auto_ptr<>, it
should have a different name.  If it has very different semantics,
it should be very different.  Counted-reference semantics is very,
very different, because reference loops are not detected, so may
not be reclaimed.  Differences that affect safe usage need to have
attention called to them.

For the same reason, "auto_pointer" is a poor choice of name.
It's easily confused with "auto_ptr".

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alwyn wrote:
>
> Maarten Hilferink wrote:
>
> > vector< auto_ptr<T> > would be a very useful construct to implement an
> > exception safe container of polymorphic objects that don't require reference
> > counting.
>
> But auto_ptr as it was designed is totally unsuitable for putting inside any
> STL container class.

Well, you can also see it the other way round:
The STL container classes as they are designed are totally unsuitable
for containing auto_ptrs (or anything else which supports "move-copy"
rather than real copy.
Now what Maarten explained is that most container operations don't
need that restriction, as do many algorithms. So it would have been
possible to distinguish between "moving" and "cloning" operations and
algorithms, and relax the requirements for the "moving" operations
to a non-const copy constructor. This would allow to put auto_ptrs
into STL containers, and to use certain non-cloning algorithms on them.

BTW, I'm wondering if an implementation which offered that could
be conforming (that is, is a conforming implementation allowed to
accept vector< auto_ptr<T> >?)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Herb Sutter wrote in message <3498e370.755726026@nr1.toronto.istar.net>...
>because of magic involving the copy ctor's taking a non-const
>reference, a lot of unsafe usage is intended to be disallowed (e.g.,
>vector< auto_ptr<T> >).
>
>By "intended to be disallowed" I mean that, though I suppose you could
>deliberately set out to write a wrongheaded but conforming implementation
>of vector<> that would still allow this, it would be hard.

vector< auto_ptr<T> > would be a very useful construct to implement an
exception safe container of polymorphic objects that don't require reference
counting.

The problem is that the copy ctor of auto_ptr objects transfers ownership,
which therefore takes a non-const reference.

A vector can be implemented in such a way that the copy ctor of
vector::value_type is only used to "move" objects,
where a "move" operation identifies making a copy after which the original
object is NEVER accessed anymore for other operations than destruction.

In general, when algorithmes only use a copy ctor to "move" objects,
they should allow the ctor's to take a non-const reference, for example to
support ownership transfers.

At this moment, a vector requires of its type parameter T to have a
copy ctor taking  a const reference. This restriction could be relaxed by
only requiring that
the repetitive insert operation ( insert(const value_type&, size_t ); ) and
the related constructor require
a const copy constructor while the one element insert and push_back should
not require the value argument to have a const copy ctor.

A different case should be made for algorithms that do continue to use a
source object
after generating a copy, such as certain sort algorithms that create
temporary copies;
it is clear that they should not work for types with copy ctor's taking a
non-const reference, such as auto_ptr<T>.

Note that also the swap operation works on objects with non const copy ctors
such as auto_ptr<T>

swap(T& a, T& b) { T tmp(a); a=b; b=tmp; }


Since bubblesort only uses compare and swap, the existence of sort
operations that can be performed on auto_ptr is clear.

P.S. I liked what I read about the new definition of auto_ptr: Just plain:
"if it points to something it is owned",
which is more elegant than using hidden mutable bits to indicate ownership.

>See GotW #25 (www.peerdirect.com/resources/gotw025a.html#Solution) for a
>detailed discussion, posted when the change was adopted.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Maarten Hilferink wrote:

> vector< auto_ptr<T> > would be a very useful construct to implement an
> exception safe container of polymorphic objects that don't require reference
> counting.

But auto_ptr as it was designed is totally unsuitable for putting inside any
STL container class.

Personally I avoid auto_ptr (I don't understand the current one, for a start,
and there's nothing more dangerous than using things you don't understand) and
have "rolled my own" pointer classes for various purposes.


Alwyn



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]