2009/3/20 Václav Haisman :

Yang Zhang wrote, On 20.3.2009 10:20:

...

Is there any advice on taming (1) the generated code size and/or (2) the What do you want to tame here? Sizes of executables are IME not a problem, unless you are on severally constrained embedded platform. Few megabytes of executable are usually insignificant compared to huge data sets that acompany it.

This is a naïve view at best. Commercial software, especially downloadable software, can be very sensitive to application size both due to the perception of bloat as well as the desire to improve adoption by reducing the barrier of entry. This counts both for adding new pre-compiled DLLs as well as the additional code size from template instantiation. I think that most Boost library maintainers are sensitive to the issue of code size, and that the libraries that implement non-member non-template function do so in a compiled library *because* they wish to control code bloat. If there examples you see in the code where this is not the case, there may be someone on the list who could give an engineering rationale for why that is. HTH, Christopher

Václav Haisman wrote:

Any decent compiler supports precompiled headers. Those help quite significantly with compilation time of source that uses Boost, IME.

I (and others) have found that precompiled headers don't actually help that much with build time. It only saves on parsing and name lookup time, not on code generation time. -- Yang Zhang http://www.mit.edu/~y_z/

On Sat, Mar 21, 2009 at 11:05 AM, Raindog wrote:

Yang Zhang wrote:

...

Václav Haisman wrote:

...

Any decent compiler supports precompiled headers. Those help quite significantly with compilation time of source that uses Boost, IME.

I (and others) have found that precompiled headers don't actually help that much with build time. It only saves on parsing and name lookup time, not on code generation time.

In my experience, code generation time is minuscule compared to the rest of the process, especially with libraries like spirit and xpressive.

Whether or not precompiled headers lead to faster builds is besides the point, because they increase coupling. The point of good physical design is to reduce coupling. Reduced coupling has many benefits beyond its effect on build times, in fact it often leads to slower "full rebuilds". Also, good physical design sometimes requires compromises with logical design, type safety, or even performance. The problem is that bad physical design has no measurable effects on anything until it's too late. Once it becomes a problem, reducing physical coupling is very difficult. Boost with its header only nature is beyond that point, IMO. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode