What I find strange is that Boost librariy developers, in general, seems to agree that template bloat is of no or little concern, #include dependencies is of no or little concern, and compilation time for end-user is of absolutely no concern.
Of course it's a concern - some of us do try and minimise template instantiation - there was even a tool for profiling template instantiations posted around here somewhere. Some of us also provide C API's for things like Boost.Regex and Boost.Math so that folks that are only concerned with "trivial" use cases can gain faster compilation times. Some of us also provide simple (fast to compile) forward declaration headers that omit any template implementations - the forward header can be used in most places to speed compilation, while instantiating used templates only in one place - a good way to keep track of which templates are actually getting instantiated as well. Having said that, precompiled headers almost completely negate the additional cost of #including header only libraries anyway.
You just said what I was thinking about. There is some kind of Urban Myths in Boost community
- Headers always better then sources.
Because it's something we're often asked for. There are folks who have told me that they won't use Boost.Regex precisely because it has separate source - even though that reduces code bloat and yes compilation times too for common use cases (the most heavily used template are instantiated in the library and *not* in your object files. There should be no more code bloat than for a non-template library *unless* you misuse it.
- Inline functions is best way to improve performance. - Concepts are **always** better then inheritance (even if they triple the size of the code).
Sad.
No not sad at all - we should all use the best tool for the job in hand. If that's inheritance so be it, if that's template so be it. To pick two extremes - a GUI library is a perfect case for inheritance, where as Math lib is IMO a perfect case for templates. In both cases if the implemenation and design are poorly done then the result can be frustration. But that's no excuse such sweeping statements.
I really hope that someday there would be boost-stable, boost-abi or just boost would become stable. I think it would be great if that stability would be official and supported part of original boost.
I don't think that Booster is the way to go because I created it for my partial needs rather needs of Boost community.
For example:
- Booster.Thread is just wrapper of pthreads/pthreads-win32 with boost like API.
Oh please no!!! Why should I be forced to use a GPL'ed external library rather than a "first class citisen" that talks to the platform API's directly.
- Booster.Regex is just a wrapper of PCRE.
Oh heavens. So lets see... no wide character support, no support for segmented containers (think really large texts stored in discontinous memory - I've had people using this support to search multi-gigabyte texts that could never be stored in memory or searched via a C interface). BTW do you realise that Boost.Regex has had an ABI stable POSIX-standard compatible C interface for the last um.... 12 years.... and yes that's since before Boost existed. Apologies if this has turned into a rant, but there are so many misconceptions and myths here that I really didn't know where to begin. I'll end with this thought: "templates generate no more code bloat than non-templates unless they are used gratuitously". For example instantiating vector<int> and vector<long> in the same program on a platform where int and long are the same size should probably be considered a mistake. But that's no reason to ditch std::vector, just to be sensible in ones usage. Regards, John.