Re: last stab at alternative pointer support

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

> Two remarks: eventually everything would have to be uglified, thus not using_const_cast but something like __using_const_cast. Much more important: do you have a definite plan for containers like <vector>? I suspect many users expect the relatively simple <vector> to work well with alternate pointers and I hope there are no specific difficulties there!

I've just looked at stl_vector.h, and it looks pretty easy (I need to
have it use_Tp_alloc_type::pointer in _Vector_impl, which has no ABI
implications.)  The only other issues might arise from the use of
non-standard pointers with __gnu_cxx::__normal_iterator<>.  I'll get
started on vector next.  At this point I've done basic_string, and
just need to double check that work (for ABI issues) before posting
it.

My intention was to work this change for all standard STL containers
first, and then on to TR1/TR2/extensions; gradually enabling this for
all containers.

Re the 1st point: I'll use any requested name.  cast_to<T>::using_XXXX
was taken from a convention I saw Ion Gatzanaga use in
Boost.interprocess offset_ptr, and I thought it was a nice readable
name.  I'll change it to whatever you require
(__cast_to<T>::__using_const_cast or __cast_to<T>::using_const_cast ?
As a non-standard class, it probably should go into a namespace which
clarifies that it's an internal implementation detail. (gcc_cxx:: ?)
Any guidance there is appreciated.

Also, I should have been consistent in the _Rb_tree code, and used
cast_to<> for all casts, not just const casts.  While I didn't really
need it, using cast_to<> everywhere in that code would help to
visually reinforce, to anyone working on it, that any new casts added
to the code should likewise use the cast_to convention.  It also helps
make the contract for custom pointer types clearer (explicit). I'm
thinking here of how to avoid having entropy break the custom pointer
support once it is enabled, and of how to make the coding conventions
necessary to support custom pointer types as clear as possible.

Bob