build times and Boost.Function
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)? wkr.
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
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 & );
A similar thing works in <= 1.35, but you have to take account of allocators, IIRC. And when you actually need the include, it is quicker to include <boost/function/functionN.hpp> than boost/function. Here N is the arity of the function you use (cannot vouch for the full portability of this but works with modernish VC and GCC).
AMDG gast128 wrote:
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)?
I don't think there's a problem with having an include guard on boost/function.hpp Please create a ticket at svn.boost.org In Christ, Steven Watanabe
I'm trying to create a type of argument which can occur in the language skill. What do you think? Any other suggestions? #include <boost/variant.hpp> #include <vector> #include <boost/shared_ptr.hpp> struct CSkillType:boost::variant<int, double, char, std::string, boost::shared_ptr<std::vector<struct CSkillType> > > { }; A method callable from skill (and provided in some DLL) would probably look like: CSkillType function_name(const CCppDataInterface &_rCPPData, const std::vector< CSkillType> &_rSkillArgs);
AMDG peter_foelsche@agilent.com wrote:
I'm trying to create a type of argument which can occur in the language skill. What do you think? Any other suggestions?
#include <boost/variant.hpp> #include <vector> #include <boost/shared_ptr.hpp>
struct CSkillType:boost::variant<int, double, char, std::string, boost::shared_ptr<std::vector<struct CSkillType> > > { };
http://www.boost.org/doc/libs/1_35_0/doc/html/variant/tutorial.html#variant.... In Christ, Steven Watanabe
nope -- shared_ptr is not necessary -- auto_ptr would suffice: #include <boost/variant.hpp> #include <vector> #include <memory> struct CSkillType:boost::variant<int, double, char, std::string, std::auto_ptr<std::vector<struct CSkillType> > > { };
- including <boost/type_traits.hpp> give also a huge latency
Did you try to include the specific boost/type_traits/xxx.hpp files you need rather than the whole type_traits.hpp? They are here precisely for that, AFAIK.
Yes normally I only include the one needed. However it was just meant to be illustrative. I have to investigate it better, but it may well turn out that some headers of type_traits are just to heavy.
participants (6)
-
Bruno Lalande -
Emil Dotchevski -
gast128 -
Pete Bartlett -
peter_foelsche＠agilent.com -
Steven Watanabe