5 ms·

Please tell what is wrong with libraries such a datetime, regex, filesystem, bind, shared_ptr, string, test, uuid, just to name the ones I use regularly. Also p

by roel_v 15y ago

Please tell what is wrong with libraries such a datetime, regex, filesystem, bind, shared_ptr, string, test, uuid, just to name the ones I use regularly. Also please tell what you would suggest as replacements, and why they do not share the deficiencies the boost versions do according to you. It's easy to hate on templates, and not is all perfect in C++ or boost, but boost is the best thing to happen to C++ to make it easier to use, or rather to alleviate some of the most annoying and unnecessary drawbacks of the language. I'm not questioning your expertise, I'll take your word for the accomplishments you mention - but your apparent disdain for it is, to put it mildly, lightly substantiated and shows more signs of ideologically fueled hatred than of a deep understanding of the negative sides of something that can only be developed through much experience.

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 ...
asher 15y ago
Well, off the top of my head - and I may be missing some of the awesomeness of boost: shared_ptr - Yes, even non-boosters like this. regex - pcre string - stl string bind - if this is what I think it is, please don't use it. Future maintainers of your code will be grateful. Having said that, C++ is a large world, and choosing to use these Boost components is perfectly valid.
- astral303 15y ago
  Anyone care to elaborate on the evils of boost::bind? Maybe from experience? I used boost::bind and boost::function in VC6 code of all places and I thought that the resulting code turned out to be pretty decent (I think newer compilers let you use slightly less verbose syntax), and I really liked having the functionality of being able to pre-bind certain arguments. For example, I had a menu item click handler that I was able to bind a call to a unary method, but with different parameters. I thought the resulting code was simpler overall (and easier to refactor).
  - asher 15y ago
    Well IIRC it was a tempting way to replace for-loops with direct list operations ala Python, Ruby etc. But the amount of syntactic noise and cognitive load seemed too much for the added leverage. Our code had sufficient complexity that I didn't want one more oddity (as many would see it) to explain. But for a small team, or a team that's all on the same page, maybe it's good. Sorry to say there's no dramatic story of code explosion here!
    - FooBarWidget 15y ago
      I wouldn't use it for for-loops either, but man, boost::bind is so handy when compiled with boost::function! I used to use function pointers and 'void *userData'. If I wanted to pass additional data to the function then I have to allocate a structure and not forgetting to free it later which resulted in a lot of boilerplate code.
- tptacek 15y ago
  And maybe they shouldn't like shared_ptr so much! It's a source of memory lifecycle bugs; everything touched by shared_ptr needs to be under the shared_ptr regime or carefully bridged to it. boost::bind seems more like evidence in the case against C++ than an advertisement for boost.
CJefferson 15y ago
First of all, my original post was writen late at night, and I should perhaps have given more care to it. There are some good parts of boost. shared_ptr, bind and regex are now in the C++ standard library. uuid is an interesting example, as it really doesn't have any reason to be 'in' boost. It is a small, self-contained library which (I understand) does one thing very well. In any other language it would just be in the standard package repository. However, for some reason in C++, instead everyone wants to get into this one bundle of packages. The problem is, because boost is monolithic, the temptation to developers is to start pulling in some boost::spirit, or boost::phoenix. I find these libraries fascinating from the point of view of what can be achieved in C++, but for day to day maintenance they cause serious problems. The problem (which I could have better articulated) is that the messier, templated parts of boost end up being seen as 'best practice', or libraries that people should use. I wold much prefer something which lets me easily install just uuid, or boost::optional (another great tiny boost library). There are of course various solutions. I could install a stripped-down boost, or just introduce strict coding standards.

by roel_v 15y ago

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

asher 15y ago

Well, off the top of my head - and I may be missing some of the awesomeness of boost: shared_ptr - Yes, even non-boosters like this. regex - pcre string - stl string bind - if this is what I think it is, please don't use it. Future maintainers of your code will be grateful. Having said that, C++ is a large world, and choosing to use these Boost components is perfectly valid.

astral303 15y ago
Anyone care to elaborate on the evils of boost::bind? Maybe from experience? I used boost::bind and boost::function in VC6 code of all places and I thought that the resulting code turned out to be pretty decent (I think newer compilers let you use slightly less verbose syntax), and I really liked having the functionality of being able to pre-bind certain arguments. For example, I had a menu item click handler that I was able to bind a call to a unary method, but with different parameters. I thought the resulting code was simpler overall (and easier to refactor).
- asher 15y ago
  Well IIRC it was a tempting way to replace for-loops with direct list operations ala Python, Ruby etc. But the amount of syntactic noise and cognitive load seemed too much for the added leverage. Our code had sufficient complexity that I didn't want one more oddity (as many would see it) to explain. But for a small team, or a team that's all on the same page, maybe it's good. Sorry to say there's no dramatic story of code explosion here!
  - FooBarWidget 15y ago
    I wouldn't use it for for-loops either, but man, boost::bind is so handy when compiled with boost::function! I used to use function pointers and 'void *userData'. If I wanted to pass additional data to the function then I have to allocate a structure and not forgetting to free it later which resulted in a lot of boilerplate code.
tptacek 15y ago
And maybe they shouldn't like shared_ptr so much! It's a source of memory lifecycle bugs; everything touched by shared_ptr needs to be under the shared_ptr regime or carefully bridged to it. boost::bind seems more like evidence in the case against C++ than an advertisement for boost.

CJefferson 15y ago

First of all, my original post was writen late at night, and I should perhaps have given more care to it. There are some good parts of boost. shared_ptr, bind and regex are now in the C++ standard library. uuid is an interesting example, as it really doesn't have any reason to be 'in' boost. It is a small, self-contained library which (I understand) does one thing very well. In any other language it would just be in the standard package repository. However, for some reason in C++, instead everyone wants to get into this one bundle of packages. The problem is, because boost is monolithic, the temptation to developers is to start pulling in some boost::spirit, or boost::phoenix. I find these libraries fascinating from the point of view of what can be achieved in C++, but for day to day maintenance they cause serious problems. The problem (which I could have better articulated) is that the messier, templated parts of boost end up being seen as 'best practice', or libraries that people should use. I wold much prefer something which lets me easily install just uuid, or boost::optional (another great tiny boost library). There are of course various solutions. I could install a stripped-down boost, or just introduce strict coding standards.