Re: [boost] auto_vector - vector with auto_ptr semantics

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-02-03 16:23:11

> From: "Rainer Deyke" <root_at_[hidden]>
> > It sounds like your 'auto_vector' avoids some of the problems of a
> > container of auto_ptrs by conceptually being a container of vanilla
> > pointers.  Unfortunately this has its own set of problems.  Consider:
> > 
> >   auto_vector<Cat> cats;
> >   cats.push_back(new Cat);
> >   cats[0] = new Cat; // Error: memory leak
> 
> With my current version, yes this is unfortunately true.  I know 
> enough not to do that, and so it has never been a problem for me.
> I regard auto_vector as being convenient and not full proof.  
> 
> If more safety is required, I guess we could look at making 
> operator[], front, and back return values rather than references.
> But it would still cause a leak if you did a 
> 
>   *cats.begin() = new Cat;

How about having the interface always dealing with Cats, not pointers 
to Cats? Then the above is a syntax error, as *cats.begin() will be a 
reference to a Cat, not a reference to a pointer to a Cat. You would be 
safe against anything short of:

*cats.begin() = *(new Cat); 

and that I decline to protect programmers from their own stupidity 
for...

My preference is to make the functions which look like vector's act 
like vector's, so all of push_back, etc, pass by value (possibly 
slicing). However, you should supply some other member functions which 
'adopt' a passed-in pointer and place it in an appropriate place, 
avoiding the copy ctor:

cats.adopt_back(new Cat); 

The only issue I see with this interface is that the standard 
push_back, insert, etc, won't behave polymorphically, and this 
container supports polymorphic containment just fine. But since none of 
those functions in STL containers behave that way, this is IMHO not a 
big flaw, as long as functionality is supplied to allow the polymorphic 
behavior when someone desires it. A second potential issue might be that

cats[0] = Calico(...);

would slice, perhaps non-intuitively. Again, I think anyone working 
with polymorphism needs to be aware of slicing possibilities anyway, so 
this is also not a big flaw.

An alternative safe interface would be to have all of the various 
insertion statements (and operator[], which returns a non-const 
reference to an auto_ptr in this scheme) take an auto_ptr instead of a 
straight pointer. This makes the allowed polymorphism a little more 
obvious, and means that accidental adoptions/leaks won't happen. The 
problem as I see it is that begin() now has the semantics of a pointer 
to a pointer to the contained object, which is completely at odds with 
the STL; trying to use algorithms looping over Cats requires 
boost::indirect_iterator when IMHO this should be contained in the 
container's iterators. So while I would probably use this latter 
interface, I prefer the other.

> Or I guess we could go the whole hog and return some sort of 
> proxy that deleted the current pointer on assignment.

> But I don't know if the added safety of either is worth the 
> trouble.  What do others think?  Keep it simple or make it safe?

I think there isn't any proxy necessary in the scheme I would propose. 
The only necessity is to write new iterator types. For that, you can 
use boost::indirect_iterator, though in this case and for orthogonality 
I would rather see it written explicitly. You could I suppose write a 
proxy which prevented (at least simple-minded) slicing possibilities. 
That might be neat, and probably wouldn't be too hard to do, but as I 
say I don't think it is necessary for a useful class, as long as 
functions are provided which do not slice.

George Heintzelman
georgeh_at_[hidden]