
Allocators are conceptually indepent from the containers that use them. They can be useful anywhere memory has to be allocated. They have to be parameterized so you allocate the correct size and invoke the correct copy constructor. All the STL containers allow you to use the default allocator and the argument supplied to the allocator template parameter is the element parameter supplied. to the container. That's why you are only required to specifiy the element type when declaring most container class instantiations. Like std::vector<int> MyIntVector; I don't know what you mean when you say "vector is the only container that actually allocates from passed-in allocator." All containers allocate memory for a copy of the element you add. That is why one of the requirements for user-defined types to be stored in STL containers is that they have to be copy-constructible.
it seems like it would have been simpler to just use member templates in a non-templated allocator class.
I don't see how much simpler that would be but I may not be understanding what you mean. The interface for allocators specified by the STL is actually pretty simple.
Parametrised allocators also mean that nested containers have exponential space requirements for their names, which actually crashed my compiler once when I tried to make a deeply-nested container structure in some recursive-slowdown experiments.)
I'd say that has more to do with your compiler and the general hazards of
recursion. There is no infinite capacity for recursion whether it be your
compiler's symbol table capacty (or it's inability to simplify the symbol
table) or the limits on stack space at run time.
----- Original Message -----
From: "Scott McMurray"
On 19 March 2010 14:02, Eric Whitcombe
wrote: Sorry, if this is a little late to be helpful but I thought I'd add this for historical purposes for anyone looking at this thread to deal with their own problem. All STL containers use allocators to allocate and initialize the memory to store the _elements_ in the container not the node structure. The containers definition of the data structures that support the implentation details are purely internal. The allocator interface is paramterized on the type of the container element.
On that note, does anyone know why allocators are parametrised at all?
Since std::vector is the only container that actually allocates from passed-in allocator, it seems like it would have been simpler to just use member templates in a non-templated allocator class.
(Parametrised allocators also mean that nested containers have exponential space requirements for their names, which actually crashed my compiler once when I tried to make a deeply-nested container structure in some recursive-slowdown experiments.) _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users