From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2007-09-23 14:31:36
O/H Larry Evans ÎγÏαψε:
> On 09/22/07 08:00, Achilleas Margaritis wrote:
>> O/H Sebastian Redl ÎγÏαψε:
> [snip]
>>> Then first you need the node allocator:
>>>
>>> typedef typename Alloc::template rebind<node<T> >::other node_allocator;
>>>
>>> Then you can get the new allocator's pointer type:
>>>
>>> typedef typename node_allocator::pointer node_ptr;
>>>
>>> class node
>>> {
>>> T elem;
>>> node_ptr next;
>>> node_ptr prev;
>>> };
>>>
>>> Don't forget to construct the node_allocator member you'll hold from the
>>> allocator you're passed in. All allocators must have a templated
>>> constructor for this purpose.
>>> Something most implementations do, by the way, is that they are written
>>> in such a way that EBO applies to the allocator if it has no state.
>>>
>> But STL containers do not use the rebind struct for their internal
>> allocations or for their member pointers. They just use T* instead of
>> allocator<T>::rebind<U>::pointer.
>
> The main_stl.zip in boost-vault/memory uses Sebastian's suggestion and
> it seems to work. It runs a little std_list test, then a GCBench
> with std:pair, then GCBench with std_list<., gc_allocator>.
>
> As (I think) you're pointing out above, the std_list<T,gc_allocator<T> >
> would define gc_allocator<T>::pointer as gc_ptr<T>, which is
> never used in std_list at all because the std_list stores the
> complete T (not T*) in std_list<...>::node. I can see where this
> would be confusing and is a shortcoming of the allocator model.
> It just happens to work in this case.
I am not really following you. Does your STL list class use the class
gc_allocator<T> or not? and if it does, does it use it fully for all its
operations or for some of them?