On Fri, Aug 8, 2008 at 2:05 PM, gast128 <gast128@hotmail.com> wrote:
Dear all,
this would be my 3 post on build times and Boost, since we develop a fairly large system (> 3000 classes) and use Boost a lot.
Rebuilding the complete system takes about 2 hours on my home pc (DELL P4 2GHz, 512 Mb) and about 1 hour on my pc @ work (DELL G280, P4, ht, 3.0 GHz, 1 Gb memory). We already use precompiled headers and tend to forward declare as much as possible.
Using some of the Boost components in headers is just out of the question because of the increased build times: - exposing the Boost.MultiIndex headers in a much used header drammatically increases build times - same argument for <boost/variant.hpp> - including <boost/type_traits.hpp> give also a huge latency
However I also notice that Boost.Function does not have an include guard. Boost.Function is used a lot and exposed through a lot of headers in our code (since they often define a callback interface). Adding an include guard myself drops the build time for a test project dramatically if Boost.Function is included recursively:
- include guards + pch 0.42 - include guards 0.35 - normally 1.52
Is there a reason that <boost/function.hpp> does not have an include guard? Does it harm when adding one (or using a wrapper around it, i.e. "incboostfunction.h" which has an include guard)?
If you need boost::function just to declare a function that takes a boost::function as parameter or returns it as result, with boost version 1.36 you can do: namespace boost { template <class> class function; } void foo( boost::function<void(whatever)> const & ); (no need to include anything.) This isn't documented, but it works and perhaps should be documented, or at least provided in a boost header file. I've also noticed that boost::variant.hpp is huge. The most general usage it supports is rather complicated (it supports recursive variants, etc.) but even with that in mind it pulls in too much code for my taste. I have been thinking that I'd like a separate, lighter variant implementation, even if it is less complete. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode