Re: Ext pointer vs N2913

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

Paolo & libstdc++,

Thanks for bringing this to my attention.  Gave n2913 a quick read.
It makes sense, but I think the proposal inadvertently breaks the
ability to have alternative pointer representations in iterators.

Key example of the problem: list<T>::iterator, as value_type is T,
pointer is normally T*.  The iterator most likely needs to point to
some internal node type of the list, not just to T.  Passing
allocator<T>::pointer to it does not tell it the type of
pointer-to-node, nor provide any means to derive that.  Based on the
template parameters proposed it would have to use a standard pointer
to a determined node type, in all cases, it would have no other
option.  I think the reason I was passing allocator to
forward_list<T>::iterator was to allow it to rebind to a pointer type
pointing to nodes in the list.

The scary initialization is nice, however, so here are some possible
resolutions to this:

(a) Support rebind<> independent of the allocator.  i.e. An
independent rebind structure which can be specialized by non-standard
pointer types.  Something like std::rebind<pointer,valueType>::other
yields a pointer-to-valueType from pointer, without any regard to
allocators.  Now iterators can derive pointer types from any single
passed pointer type (allocator::pointer).

(b) Rather than passing iterators a specific pointer type, allow them
to receive the allocator's rebind struct (or something similar) via a
template template parameter, constituting a 'pointer family' argument.
 It provides the iterator with the ability to determine any pointer
type it may require.  (If this rebind type is the same for all
instances of allocator<T>, the advantages in reduced code are still
achieved.)

(c) Give up.  Assume all iterators use normal pointers for internal
storage, and base them all off value_type directly.  i.e. Containers
can use alternative pointers, but not their associated iterators.
Definitely hurts some smart pointer schemes.

Not coming up with any better ideas than those 3.

We could adopt a convention like (a) within libstdc++ using an
ext::rebind, but we need to be clear that the rebind<> logic of any
allocator is expected to yield a pointer of a different type from the
same 'family' of pointers in all cases.  In other words, compile time
assertion: allocator<T>::rebind<T2> == allocator<T2>::pointer, for all
T, T2.  We can then adhere to this proposed standard and loose no
functionality, I think.

- Bob

On Mon, Sep 28, 2009 at 9:42 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi Bob,
>
> at the last ISO C++ Meeting, in Frankfurt, Bjarne presented this paper:
>
> ?http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf
>
> For now, I don't think people are inclined to incorporate it as-is in
> the standard, mainly because of ABI-breakage issues, but nonetheless,
> there is a strong consensus about its main points. In particular, as you
> can see, it would not be possible anymore to have an X::iterator with
> X::allocator as type argument, at variance with our current
> std::forward_list... I'm assuming people believe (will double check in
> Santa Cruz) that extended pointers are possible anyway within these
> constraints, but I'm not clear how... Could you possibly provide your
> feedback about this issue on the libstsc++ mailing list?
>
> Thanks,
> Paolo.
>