Re: auto_ptr bug

[Brad Garcia <bgarcia at laurelnetworks dot com>]

On Mon, 10 Apr 2000, Matt Austern wrote:

>  > Shouldn't that constructor take a "const auto_ptr&" ?
> 
> No.  The auto_ptr interface may well be broken, but in this respect it
> conforms to the C++ standard.  See 20.4.5.1, paragraphs 2-3, and
> 20.4.5.2, paragraphs 5-6.

Unfortunately, I only have access to the Dec 96 working paper, in
which it is a const.  I take it that this has been changed?

> The C++ standardization committee thrashed this out at great length.
> The constructor doesn't take a const auto_ptr& because it has to
> modify its argument.  Those sorts of things would change the fact,
> though, that auto_ptr's constructor really does modify its argument,
> and in a very visible way.

Looking at the new version, the internal pointer gets set to 0 when
it loses ownership.  Old versions of auto_ptr didn't work this way -
it released ownership, but kept the pointer, and ownership (I assume)
was mutable.

So, getting to my real problem: how can I make a map full of Foo's, and
have them get destroyed when the map is destroyed, given that the Foo's
themselves cannot be copied?

I thought auto_ptr was the answer, but apparently it isn't anymore?
Or should pair<> define another constructor that takes non-const
arguments (this is what prevents me from using auto_ptr in a map<>)?


Brad Garcia