Re: std::ext STL (was: Re: design doc on alternative pointer support)

[Bob Walters <bob dot s dot walters at gmail dot com>]

"Phil Bouchard" <philippe@fornux.com> wrote in message
g81m4a$ddc$1@ger.gmane.org">news:g81m4a$ddc$1@ger.gmane.org...

> Ok it turns out if we delete the node pointed to by the "prev"  
pointer and
> iterating forward with "next" then everything will be perfect...

OK, so a routine like clear() should be implemented like an iterative  
erase() with the 'unnecessary' overhead of removing all references to  
the object being removed, just in case deallocate() does nothing and  
relies on smart pointer behavior.

I also reached the conclusion that iterators *should* reflect the  
pointer typedef from the allocator since the allocator is provided as  
a policy to the container, and the container in turn yields the  
iterator types.  (Call it a transitive effect.)

One other question remains: I noticed that your pointer lacked the  
means for implicit conversion to a real pointer, and that you used the  
convention of "&*" throughout the list<> code.  This reminded me of  
boost.interprocess, and the offset_ptr.  Is there a reason for not  
supporting implicit conversion?  I did notice it was a pain to work  
out the ambiguities which arose when designing the pointer class, but  
I think I've reached a point where most 'normal' pointer coding styles  
work fine for the _Pointer_adapter<> template, and I'm trying to  
determine if there are any other considerations that I have not  
thought of.

Bob