Boost as a symbol for the npm'ness of C++

[Tuxman]

I'm currently writing a rather sophisticated web software in C++ (I'll post a topic on it when I'm done, so there's finally another software of mine you can ignore ). As I - as you might know - usually prefer the KISS principle, I try not to include as many external libraries as possible, probably reinventing the wheel in a lot of places yet sticking close to the standard. (Hooray, C++17!)

During the past development I came across a lot of potentially interesting libraries which I ended up implementing myself because all of them depended on the Boost libraries, a huge can-do-everything monster of some header-only, some must-be-linked libraries which would add an indefinite amount of complexity to my application without being maintainable by me. The usual reason for the requirement of Boost is that Boost provides regular expressions and advanced file system functionality - both of which are already a part of recent C++ standards (admittedly, <filesystem> is still considered experimental).

In the light of Node.js's funny - I really don't like JavaScript - left-pad debacle: Why, just why do some C++ folks prefer huge craploads of external libraries to just sticking to the standard? Being portable is no excuse anymore, nothing is as portable as the standard.

[Shades]

Having installed only the C++ part of Embarcadero RAD Studio XE4, XE7 and XE10 on several Windows PC's, I can tell you that this takes a really long time on any of these IDEs. Think around 2 hours on a i5 at 3.8GHz with 16GByte. Most of that time is spent on building/compiling the Boost libraries. All 3GByte of it.

When you (as a programmer) have it, why let it go to waste? Right?

[Tuxman]

Why actually have it at all?

[mwb1100]

The C++ community is rather conservative compared to most other programming communities (perhaps the only large groups of programmers that are more conservative are C programmers and kernel developers).  Many still have to support using older compiler toolchains, so Boost may provide the only option for them.

I think the answer to why <regex> and <filesystem> from the standard library aren't used more often is simply because the new functionality in the recent C++ standards is new.  Even regular expressions, which was added in C++11 wasn't well implemented in GCC until 4.9 (https://gcc.gnu.org/...014-04/msg00195.html).  That's about 2 years ago, but as I said the C++ community is rather conservative.  I think that there are still occasional questions on stackoverflow about differences in regex support between MSVC and gcc.
 
I think you'll see <regex> being used from the standard more and more over time, and <filesystem> probably won't be widely used until C++17 is official.  But I think that <filesystem> will be taken up more quickly than <regex>. 

[f0dder]

As mwb1100 says, not everybody can use the latest-and-greatest compilers. It isn't necessarily about being conservative, but which platforms you have to support - whether that be commercial ones, old systems, cross-compilers for embedded devices or whatever.

Boost would also make sense if you use a large subset of it, or if you use some of the specialized stuff that aren't available elsewhere. And you don't have to build the entirety of it if you're only using parts, anyway, although going down that road quickly becomes hairy. That's one of the biggest C++ issues: header files and compilation units are sucky, it's a shame there's no module system.

In general, while not a super big fan of Boost because it's such a huge bast, I'm all for using 3rd-party code - if you need something (non-trivial) that somebody else has already written, there's a good chance you won't be doing a better job at re-implementing the wheel. And that's what usually separates the C++ crowd from the NodeJS crowd - the former tends to make informed decisions on what dependencies to take, whereas the latter pulls in anything... even doing those insane one-line-function dependencies.

[Tuxman]

if you need something (non-trivial) that somebody else has already written, there's a good chance you won't be doing a better job at re-implementing the wheel.

-f0dder (May 08, 2016, 04:02 PM)

If somebody else has written e.g. a Markdown parser class in ~ 250 LOC which depends on Boost, there's a good chance I can do it in ~ 250 LOC too and without several GiB of additional dependencies. (Which is what I did when I wrote this rant.) Third-party code is OK for me - third-party code with a trailing dependency hell is not.

I like to be able to debug my own problems.

[phitsc]

We've had issues using std::regex on arm (bugs in the std library coming with gcc). We've been using boost on the respective project anyway though.

There have been efforts to modularize boost. Don't know what state that is in though. I could imagine this being non-trivial, especially with so many individual authors involved.

[Tuxman]

gcc's stdlib is its own problem, indeed. I admit that I try to avoid gcc whenever I can, so probably my actual question is invalid for that compiler.