Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk