RE: [boost] auto_vector - vector with auto_ptr semantics

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-02-04 09:55:12

> From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> 
> > This predicament points out a general lacking in STL that 
> I'd like to hear
> > other's opinions of.  That is the concept of transforming 
> an iterator to a
> > pointer.
> 
> You mean vice-versa?

Indeed, I the concept of transforming a pointer to an iterator.  Sorry.

> > Should new containers in boost allow for
> > creating iterators from pointers?  I'm asking this first at 
> a general
> level.
> 
> It's a very interesting idea. You can't do it in all cases 
> (for example, in
> the adapted container which hides the indirection, or in most 
> std::deque
> implementations), but I think it would be useful.

Good point.  Pointer to iterator conversion would at best be just another
feature of a container, subject to being traded off against other container
features (like hidden indirection and constant time front-end insertion).

> >  A problem with
> > auto_vector is that mutating algorithms tend not to work 
> with it.  So I
> > found it better to build my own algorithms into the class, 
> in this case
> > remove_first and remove_last.  While this seems to go 
> against the original
> > spirit of STL, it proved to be quite practical.  I will be 
> interesting to
> > see whether it can be practical in a generic library environment.
> 
> In theory, "fixing swap" should handle lots of that issue 
> (you just use the
> indirect interface). Of course "fixing swap" is a big topic ;-)

This is interesting and new to me.  Would this be helpful for the removing
algorithms, or just the sorting algorithms?  
Currently, unlike the sorting algorithms, the STLport removing algorithms
are implemented in terms of operator=.  It might be that auto_vector would
have problems with algorithms even beyond the "fixing swap" topic.