You are here:

C++/allocators in std


Hi Ralph,
I usually work on basic libraries cross-platform compiled and useful for many things. Recently I started using boost which is very STD extensive and I came across something I do not understand:
std::vector<int> int_vector; // vector of ints
std::vector<int, std::allocator<int> > another_int_vector; // same type as int_vector
std::vector<int, boost::pool_allocator<int> > a_third_int_vector; // a different type from the other two
Than I dug the Internet and I found out that some people use the first, but there are other people who use the second. There is no information about why would I want to use the second and the third way to declare my std containers.

All the standard library containers allow the specification of an allocator type to be used to perform allocations, constructions, destructions and deallocations of objects they contain.

By default this is std::allocator<T> where T is the type of object managed by the allocator, and is given as the type of object stored in the container. This would typically be a wrapper around new and delete or other related compiler-specific runtime allocation support (in fact the interface would require raw memory were allocated and deleted and that objects be constructed and destroyed in this memory using placement new and explicit calls to objects' destructors).

So the first and second forms are equivalent, it is just matter of preference - some people like to be complete in their declarations.

However it is possible that there be a requirement for specialist allocation schemes - maybe, as in the third way you are asking about, it used an allocator tuned to a specific single object type and/or to give better performance for certain usage patterns. See for example the Dinkumware supplemental C++ library allocator documentation at

Most of the time such concerns will only come up if you are using containers with a very large number of items (or few number of larger items maybe?) or that have items added and removed a great deal (i.e. at high frequency).

Now the reason for using the Boost pool allocator is that allocating from a pool can be efficient when there are a lot of small objects allocated and deallocated - as in the case of int elements in a vector. For more information see the documentation on the Boost Pool Library in the Boost documentation (you are reading the Boost documentation aren't you?), online at

std::vector is usually implemented such that it allocates larger raw chunks of memory at a time than it needs and then constructs objects in that memory as required (see for example "The C++ Standard Library a Tutorial and Reference" by Nicolai M. Josuttis, section "6.2.1 Abilities of Vectors"). Thus the speed up for a std::vector may not be as great as anticipated. Using a pool allocator with a node based container such as std::list<int> may well give a more noticeable performance increase.

I should state the usual points about optimisations (and use of custom allocators could be deemed an optimisation).

1/ Don't optimise early.
2/ Don't optimise until you know you need to.
3/ Even if you know you need to optimise, don't optimise until you _know_ what is needed and where (e.g. after you have profiled the code to locate the actual performance bottlenecks). It is sad but true that we (developers) are generally bad at detecting where the time is really being spent in our code.

Hope this has been of use.  


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2017 All rights reserved.

[an error occurred while processing this directive]