steve@parisgroup.net wrote:
Greetings, As a veteran C++ programmer, I've been an admirer of the Boost library for many years. I've used it at a number of companies I've worked for, especially the SmartPtr library.
I've done a study and written some tools, to determine just how many Boost header files must be included to use some of the Boost modules. The numbers are staggering:
... This is a legitimate concern which IMO has not been taken seriously by the Boost community. To some extent it's unavoidable since it's more efficcient to have one "best" solution imported everywhere rather than replecating code. But it doesn't have to be as bad as it currently is. And it's only getting worse as more libraries get added to Boost. Here's what I suggest for boost users such as yourself: a) don't use "convenience headers" which suck in all the headers in a library rather than just the one's used. It seems tedious because one has to read more carefully to know which headers to use but it saves huge amounts of build time and diminishes "dependency surprises" which can cost a lot of time to track down. b) a few libraries "infect" your code with "spreading" depencies. Use your analysis to detect these libraries and complain about them. I have done this in the past to no effect. It did make me feel I was doing something though. If you can't get library authors to see this, you'll just have to avoid that library or fork your own copy. c) In your own code, use pre-compiled headers. This speeds up re-builds. It DOES force you to spend some time looking at how you've divided up your own code but this time is a good investment. Here's what I suggest library author's do: a) Take this gentlement's complaint seriously. b) Consider eliminating "convenience" headers. c) When writing documentation avoid depence on "convenience headers". This seems like it adds some work - less conveniece - but hels addressing this man's problem. Here's what Boost can do. Something like: a) Formalize the comcept of boost library "levels" i) core - e.g. config, auto-link, BOOST_NONCOPIABLE, ... ii) utility - e.g. scoped_ptr, ... iii) application support - e.g serialization Every boost component would depend only on components at the same or lower level. The assignment of library level would be part of the review process. The motivation here is to support the future growth of Boost and C++ libraries in general. I see this as the fundamental requirement behind any efforts to achive "Boost Modularization" Robert Ramey