0

I tried to add to my project rather limited functionality from the Boost library, namely allocating memory for small objects from a pool with the help of the 'pool_allocator' class, and discovered that I need to add to the project dependendencies to 4 debug static library files and to 4 release static library files. I.e. 8 library file dependencies are needed for a single line like this:

boost::container::vector<int, boost::pool_allocator<int> > v;

Is there a way to using these classes without linking to the static libraries? (Maybe a certain combination of the template parameters?)

Jan Herrmann
  • 2,717
  • 17
  • 21
Al Berger
  • 1,048
  • 14
  • 35
  • So it really needs 4 libraries - the fact that you use different libraries in release and debug doesn't matter, it is still just one library (the two variants are built from the same source code). And I'm pretty sure that some of the libraries are not for the pool allocator, but for the `vector` part.... – Mats Petersson Jul 16 '13 at 07:07
  • I'm holding out for modules: http://isocpp.org/blog/2012/11/modules-update-on-work-in-progress-doug-gregor – peterchen Jul 16 '13 at 07:21
  • Mats Petersson - actually all four libraries have to do with multithreading. They are: date_time, thread, chrono and system. – Al Berger Jul 16 '13 at 09:37

2 Answers2

3

All I read about boost pool is: don't use it at all. The library is rather old (in boost 1.54 all files have copyright 2000 and 2001 except pool_alloc.hpp, which was edited in 2010) You can look here for an question about performance (look for the answer of James Kanze). If you want only to use boost, I would suggest to use another library. If you need a custom allocator, do benchmarks.

Edit:

From Pools docu:

In general, use Pools when you need a more efficient way to do unusual memory control.

So the qustion is what exactly is unusual memory control? Does it meet your special need to memory? Andrei Alexandrescu has written in "Modern C++ Design" about memory allocation and that there may be very different requirements depending on allocation and deallocation patterns. But according to this paper he isn't convinced it was a very good chapter.

So for me the final question is wether pool is better than std::allocator for the problems memory management? You have to messure it. Even with litle logic implemented in pool there might be more efficient algorithms for memory management used in your implementation. By the way one of the bugs of pool is "Boost pool library it not header only as claimed in documentation".

Jan Herrmann
  • 2,717
  • 17
  • 21
  • Boost::pool_allocator uses the pool with Simple Segregated Storage as a base and doesn't contain very much logic, but considerably improves the speed of code with frequent small heap allocations (only in the release build; in the debug build Boost's pool allocator much slower than the default one). The main overhead with the pool_allocator in terms of additional library dependencies comes from multithreading issues. So it seems that it's worth to use the pool without multithreading and implement one's own synchronization when needed. – Al Berger Jul 16 '13 at 09:33
  • Can someone advise how to declare the 'pool_allocator' without multithreading (maybe with 'boost::details::pool::null_mutex'?) and with the rest template parameters being default? – Al Berger Jul 16 '13 at 09:33
  • @ Jan : thanks, Jan. The paper is very informative and the second link contains the solution to the topic question. – Al Berger Jul 16 '13 at 11:41
0

Identify the files requried from boost, and add them to your project individually, or add a .cpp to your project that #include's the requried .cpp's. (Not really recommended)

or

generate your project files by a script, so that adding such dependencies is easy. Setting this up is a pain, but having it is great

peterchen
  • 40,917
  • 20
  • 104
  • 186