7 ms·

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

by to3m 15y ago

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.

stonemetal 15y ago
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.
- chancho 15y ago
  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.
ArchD 15y ago
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.
- buff-a 15y ago
  Item: having to think of ways to speed up your build time instead of thinking of building your product.
jpk 15y ago
> 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.
zvrba 15y ago
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.
- FooBarWidget 15y ago
  Some C++ implementations already implement symbol hashing. http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections
  - zvrba 15y ago
    This is an improvement of existing hashing scheme in ELF object files, and is completely different from what I proposed.
    - FooBarWidget 15y ago
      I know, but it is hashing nonetheless. Doesn't it effectively achieve the same goal that you're after, namely faster symbol lookup?
      - zvrba 15y ago
        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.
- rwmj 15y ago
  I'm guessing because of collisions? 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 ...

by to3m 15y ago

stonemetal 15y ago

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.

chancho 15y ago
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.

ArchD 15y ago

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.

buff-a 15y ago
Item: having to think of ways to speed up your build time instead of thinking of building your product.

jpk 15y ago

> 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.

zvrba 15y ago

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.

FooBarWidget 15y ago
Some C++ implementations already implement symbol hashing. http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections http://blogs.oracle.com/ali/entry/gnu_hash_elf_sections
- zvrba 15y ago
  This is an improvement of existing hashing scheme in ELF object files, and is completely different from what I proposed.
  - FooBarWidget 15y ago
    I know, but it is hashing nonetheless. Doesn't it effectively achieve the same goal that you're after, namely faster symbol lookup?
    - zvrba 15y ago
      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.
rwmj 15y ago
I'm guessing because of collisions? 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 ...