Other Software > Developer's Corner

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

(1/2) > >>

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 :P). 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/ml/gcc/2014-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.

Navigation

[0] Message Index

[#] Next page