Most of the messages here ignore an important detail, quoted from Scott Meyer's Effective STL, item 10: "[T]he Standard says that an implementation of the STL is permitted to assume that all allocator objects of the same type are equivalent and always compare equal... It means that portable allocator objects — allocators that will function correctly under different STL implementations — may not have state. Let's be explicit about this: it means that *portable allocators may not have any nonstatic data members*, at least not any that affect their behavior. None. Nada. That means, for example, you can't have one SpecialAllocator<int> that allocates from one heap and a different SpecialAllocator<int> that allocates from a different heap. Such allocators wouldn't be equivalent, and STL implementations exist where attempts to use both allocators could lead to corrupt runtime data structures." To summarize, std::vector<T, monotonic_allocator<T> > won't work if each vector gets a specific buffer, because another vector could possibly use that buffer instead! Thus a custom version of each container is REQUIRED unless there's a boost.test macro BOOST_STL_ALLOCATOR_EQUIVALENCE or something like that. On Tue, Jun 9, 2009 at 10:03 AM, <joaquin@tid.es> wrote:
Stewart, Robert escribió:
joaquin@tid.es wrote: On Tuesday, June 09, 2009 9:34 AM
Stewart, Robert escribió:
There's a problem with using an allocator for the node based containers: they use the allocator to allocate the elements but not the nodes. That implies free store (de)allocations for the nodes which is contrary to the intended purpose of this proposal.
Umm, I beg to differ. If we have a node-based container
xxx<T,...,custom_allocator<T> >
and node<T> is the internal node type, the container is required to do the allocation using an allocator of type
custom_allocator<T>::rebind<node<T> >::other.
The container is not allowed to do any kind of allocation using other means than the custom_allocator<X> family of allocators.
If custom_allocator<node<T> > is not specialized to do the same as custom_allocator<T>, or to use the same memory pool, then it doesn't fit the proposal.
Point conceded, but how would you do otherwise? Specifying a custom allocator is your only way to affect the container's allocation behavior. Seems like you're implying that the container wrapping approach is in some way more powerful than directly specifying the custom allocator, which is not.
Your only chance to solve the problem you mention is to make custom_allocator<node_type<T> > use the same memory pool. There's a way to do this. If you construct the container with
custom_allocator<T> a; xxx<T,...,custom_allocator<T> > x(a);
then xxx will use an object of type custom_allocator<node<T> > for its allocation needs, which perforce will be an object differnt to the allocator a you've passed; but the container is required to construct this internal allocator as a copy of a:
// inside xxx implementation custom_allocator<node<T> > internal_a(a);
So you can use this knowledge to pass info around, for instance on the memory pool to be used.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost