std::ext STL (was: Re: design doc on alternative pointer support)
Bob Walters
bob.s.walters@gmail.com
Sun Aug 17 03:42:00 GMT 2008
"Phil Bouchard" <philippe@fornux.com> wrote in message
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
More information about the Libstdc++
mailing list