Home/ Questions/Q 365201
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T13:30:52+00:00

Boost rocks, it is great and extremely powerful, but I hate it everytime I

  • 0

Boost rocks, it is great and extremely powerful, but I hate it everytime I build solution in my Visual Studio 7.1.

It seems Boost has impact on build time (not positive). I cannot remove all Boost usage from my project to compare build times but I tried it on small projects and the difference is meaningful.

I guess the problem is that Boost consists of thousands of header files which include themselves very extensively. So, when I include, say, boost/function.hpp into my header file, it may lead to including hundred of Boost headers.

Is there someone who experienced the same? Any ideas how to solve it?

Rough thoughts:

  1. Add boost to precompiled headers? At least they will be parsed and kept in one file
  2. Do explicit instantination for some Boost templates?
  3. Prepare Boost headers somehow?
  4. Do not include Boost to header files (sounds unreal)
  5. …

PS. Yep, Boost also uses hardcore templating that pretty hard to compiler I guess, so thousands of header files are not the only problem.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Naturally, including boost leads to longer compilations times – just like including any library does. Being (mostly) a template library offcourse leads to quite big performance penalty as all of the logic is implemented in the headers.

    1. I’ve had good results including (a subset of) boost in precompiled headers. However, I belive that the gain is greatest with MSVC 9. On MSVC 7 I have seen several reports saying that precompiled headers of templates frequently leads to performance penalty. Another crucial aspect determining if you’ll see performance gain is to include the appropiate headers in the precompiled header. Only include headers you frequently use, and make sure they are never changed (that is, think three times before including your own headers here)

    2. I do not know if explicit instantination has any effect, even though I doubt it. If anyone has seen any results on this (regardless compiler), it would be very interesting.

    3. “Preparing” boost headers sounds like altering them which sounds like a very bad idea to me. You don’t want to end up maintaining customized headers…

    4. May not be so unreal as you might think. Always use as many forward declarations as possible to reduce the “footprint” of each header file. Consider using the Pimpl pattern to avoid including boost headers that are not reflected in the public interface of your class (offtopic: I consider Pimpl to often be unnecessary. Instead I try to slice the classes into smaller pieces, acheiving the same result in a “cleaner” fashion). Don’t be afraid to include general, common classes (e.g. shared_ptr) as long as you’re consistent in the usage of these classes (if your using them in all your classes you wont see much gain in hiding them away from one header).

    5. Upgrading MSVC (to support parallel builds) will help. However, this is always an issue in C++. To minimize the problem, you need to be very strict and follow guidelines to reduce the footprint of your headers. Now and then you should look through the include-clauses and make sure there are nothing unnecessary included. If you’re list of includes done in the header is getting long you’re probably doing something wrong – most includes should only be in the cpp.

    • 0