Re: design doc on alternative pointer support

["Phil Bouchard" <posts at fornux dot com>]

"Bob Walters" <bob.s.walters@gmail.com> wrote in message
8C8DB82B-29D9-448C-8261-672FF30D19CC@gmail.com">news:8C8DB82B-29D9-448C-8261-672FF30D19CC@gmail.com...
>
> A copy of the pdf explaining the design of the alternative pointer
> capability is available at:
>
> http://stlshm.sourceforge.net/alt_pointers_in_stl_containers.pdf

Hi,

I am facing the same problem as yours but I am coming from a very different
path hence I have a different perspective.  Early this week I wrote a patch
we can find herein attached to this email.  My changes are very similar to
yours, I am propagating the allocator all the way up to the node but I saw
some issues we will have if we use a different smart pointer such as mine:
shifted_ptr or any other as a matter of fact like: shared_ptr.

Firstly I would recommend adding to the allocator a new typedef called
"iterator" that will define the type used inside container iterators.  This
will remove unwelcomed overhead for intensive iterator usage.

Secondly some specilized code will need to be added.  In the case of
conversions between raw pointers and smart pointers this is not a problem
because we just need adding explicit &* because this cannot be done
implicitly.  But in the case of _M_erase() and _M_clear() member functions
we will have problems because smart pointers already handle the deletion of
their object.  We'll need some sort of specialized functors over there.

Last but not least, _M_impl node cannot be pointed to by smart pointers
because smart pointers expect objects living on the heap.  This is not
always the case here because it is a member of the containers and the latter
will likely be instanciated on the stack.  The easiest solution here is to
allocate _M_impl on the heap using the allocator, just like all other nodes.


-Phil

Attachment: stl_list.h.patch
Description: Binary data

Attachment: list.tcc.patch
Description: Binary data