Re: [boost] [shifted_ptr] __normal_iterator ..?

From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-06-21 13:40:40

"Larry Evans" <cppljevans_at_[hidden]> wrote in message 
news:g3gp99$9a2$1_at_ger.gmane.org...

[...]

> Hi Phil,
>
> Even if you could find some way for your allocator to work for vector, I
> don't think it would work for other stl containers.  These other
> containers, e.g. std::list<_Tp>, use Allocator<_Tp>::pointer to point to
> other elements in the container.  AFAICT, what's needed for garbage
> collections is Allocator<_Tp>::root_pointer.  This would be
> a *smart* pointer to the head of the list in the case of std::list<_Tp>
> and all other pointer would just be _Tp*.  In the case of 
> std::vector<_Tp>, I guess the start of the vector would be a *smart* 
> pointer to _Tp[].  The iterators for a GC'ed vector would have to
> retain a copy of the root_pointer, I guess, in order to keep the
> whole vector alive if even 1 iterator were still around.

[...]

Hey Larry how have you been doing?  I moved to the South West and thus 
couldn't work on this for some years.

But it sounds we violate [20.1.5/4] by doing so as stated by Kai-Uwe Bux:

   "Implementations of containers described in this International Standard 
are
   permitted to assume that their Allocator template parameter meets the
   following two additional requirements beyond those in Table 32.
      [...]
   ? The typedef members pointer, const_pointer, size_type, and
     difference_type are required to be T*,T const*, size_t, and ptrdiff_t,
     respectively."

How strange is that because one might ask why these typedefs exists in the 
first place if we can't change them.  Besides licensing I don't see why we 
couldn't cut & paste the whole STL and make these changes; I'll try that out 
tomorrow.

[On the other hand STL should have explicit access to nodes but intrusive 
containers are already on their way and hopefully intrusive stacks too]

> Anyway, I encountered a similar problem with the policy_ptr
> library I worked on years ago.  The code used to be in
> the sandbox; hoever, I can't find it now.  However, FWIW, there's
> this post:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/155407/match=policy_ptr

Yeah there is a way to stack up the information I need by creating a 
separate list of pointers and will bypass all of this but creates messy code 
and I think STL changes is a better approach.

-Phil