Re: [Boost-users] Boost and C++ "physical design"

Christopher Currie wrote:

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 completely agree. Program size might not be a practical factor when a program is already installed on a desktop computer with 500G hard drive. But somebody sitting in a cafe and downloading the same program over free wifi onto his netbook will surely appreciate reasonable size.

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.

I'd like to be wrong, but I think I saw the issue of code size dismissed, and I am not aware of any systematic approach to measure code size impact of individual libraries. Few years ago I've did some measurement for program_options -- it terms of 'bytes of code to declare one option'. This proved fairly entertaining, but clearly, measuring code size impact of one operation may easily miss other sources of code bloat. - Volodya