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