Re: [Boost-users] build times and Boost.Function

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-08-08 17:24:54

On Fri, Aug 8, 2008 at 2:05 PM, gast128 <gast128_at_[hidden]> 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