Sometimes, you can see the negatives straight away. No experience necessary! A 40 second compile time is a pretty big negative. I wouldn't even suggest this is exaggeration; my experience with boost is not that wide-ranging, but what experience I have does include waiting for programs to compile.
(Maybe experience is even the problem. A C++ programmer might suck up a 40 second round trip time, but I bet no PHP or Python programmer would!)
Large C++ projects already tend to suffer from monstrous compile and link times. Anything that increases build times is inherently a bad idea. Iteration time has been THE major issue on every project I've worked on. Sucks up man-hours like nobody's business. All the other C++ junk... borderline irrelevant, by comparison.
There in lies the problem boost is a collection of libraries that are more or less unrelated to each other. So sure spirit is a major pile of template catastrophe, as are some of the others (boost::lambda was my introduction to something I should never do with templates.) Then you have the others. FileSystem has nary a template in sight, Asio and Thread have a few but they aren't crazy.
The presence of "octonions" in the boost library kept me from seriously considering it for like 2 years. I understand the rationale--that by making it monolithic they're getting more libraries installed on more developer's machines--but come on. If I need threads, filesystem, date_time, foreach, etc. don't make me install wave, spirit, proto, phoenix, fusion, fucking octonions.
> Anything that increases build times is inherently a bad idea. Iteration time has been THE major issue on every project I've worked on. Sucks up man-hours like nobody's business.
I'd say this is only true part of the time. Optimizing for developers' time (thus, payroll cost) is a good idea, but not to the exclusion of other costs. For instance, if you're building a web app that's grown to the point where the business's primary cost is the hardware on which the software runs, it makes sense to make technology decisions with that in mind. Trading some developer efficiency for lower data center costs is perfectly reasonable.
Not to mention link times: templates generate HUGE mangled symbols, with corresponding increase in memory and time as all those strings have to be stored and string-compared.
I've long wondered about why doesn't any C++ compiler implement symbol hashing? As in: replace symbol names with symbol hashes (SHA1) in the symbol table, and emit an extra section that maps hashes back to mangled names. Linker could do all of its work using hashes, and would map them back to regular symbol names only when generating the final debug info file.
The OCaml compiler uses hashes for some symbols. It has to have extra discrimination code in the linker to deal with potential collisions, and it can reject valid programs because of this. That's in theory, because I've never seen a program rejected, except for a synthetic program that someone made to demonstrate hash collisions ...
It is not as fast as it could be. It is an implementation of ordinary hash table, meaning that also a successful search requires comparing two strings several kB long. What I propose is to reduce ALL symbols to their hashes (SHA1 is 20 bytes) and to "dehash" them only after linking has been done.
Collision in hashes is of only theoretical interest when you consider SHA1 or SHA256.
I don't know how large your project is, but you could use a parallel build solution such as Icecream to dramatically shorten your build time, especially if your project is composed of numerous compilation targets.
(Maybe experience is even the problem. A C++ programmer might suck up a 40 second round trip time, but I bet no PHP or Python programmer would!)
Large C++ projects already tend to suffer from monstrous compile and link times. Anything that increases build times is inherently a bad idea. Iteration time has been THE major issue on every project I've worked on. Sucks up man-hours like nobody's business. All the other C++ junk... borderline irrelevant, by comparison.