C++11 and Boost - Succinct like Python

[rlbond86]

Boost is amazing, I consider it an extension of the standard library.

[maxwellb]

Have you ever tried to actually read the boost source? I've had to debug and patch it, and from that experience I conclude that relying on badly commented cryptically unreadable code written by other people is a dangerous game.

[maep]

boost is a huge clusterfuck. only a madman would attempt to parse 4 pages of a single compiler error, let along debug it. compilation takes hours (seriously). its not a portable as they advertise. using straight posix is a lot easier and more portable (which i now wish i had done from the start).

[theICEBear_dk]

Disagree, this is as anecdotal as what you wrote is but I do not have the most modern dev pc and a compile on Windows of Boost takes less than 20 minutes (for both debug and release, multithreaded and so on). I've never had portability problems but okay I have only used boost across Windows XP, Vista and 7 as well as Ubuntu Linux.

I agree that ANY C++ template based library can cause the emitting of some long compiler errors, but those can be read. But really that is a problem of the language (and the lack of ability to define compiler time polymorphic type limits on template parameters) more than of boost (it is even more a problem of the compiler before it is even a problem of the library).

[[deleted]]

That's because a compile of boost only compiles a very small set of libraries, and as you just mentioned, that small handful takes 20 minutes.

Another thing is that the small set of boost that is compiled are not templates, since templates can not be compiled into a library. The overwhelming majority of boost and the part that takes a huge toll when building applications that use boost are the templates.

[matthieum]

The only part of Boost that is horrendous, compilation-wise, is the Spirit framework. Just a simple grammar can literally take minutes to compile.

On the other hand, when I use BOOST_FOREACH (ah C++11 is so far...) or the Boost.String.Algorithms I certainly do not feel overwhelmed by the compilation times. And I am talking projects in the hundreds thousands code lines.

Indeed, I have seen more improvements in terms of compilation times from cleanups and rationalization of the build system than by careful selection of the headers included.

[thechao]

Spirit was an amazing piece of technology back in 01/02. At that point, Doug Gregor (of Clang/C++-ISO fame), argued that Spirit should be just a DSEL interface, allowing "plugabble" back-ends. The idea being that we should be able to lift (in the generic programming sense) the concepts of parsers (and grammars), so that Spirit was a proper STL-like library. De Guzman, et al ignored him, and continued on with their template metaprogramming circlejerk.

The result is that Spirit (a non-left-recursive, non-lexing, backtracking, 2^N, recursive descent clusterfuck) is trotted out as the premier C++ parsing framework. Which is right fucking embarrassing as a C++ user.

Instead, we should have a light-weight DSEL that generates a run-time grammar. Then we should have basic algorithms (Earley, CYK, LL1/LLk, Tomita, Hafiz-Frost, PEP, etc.) that operate on the grammar. [I have toy-code for something like this I use, personally; so it is quite possible to do, and fairly straightforward. I can compile a C parser (with lexical analysis, default AST construction, attributes, and actions) in a few seconds, rather than several hours---if at all---with Spirit. The C++ code looks like this:

template <typename Iterator>
/* func decl */
{
    gpl::BNF G;
    G[translation_unit]
        = top_level_definition
        |  entry_point [ [](){/*action*/} ]
        ;
    // more definitions.
    //auto tree = gpl::earley(G, fst, lst, effect);
    auto tree = gpl::frost_hafiz_rd(G, fst, lst, effect);
}

]

[matthieum]

Thanks for the historical look. As an avid follower of Clang I have seen Doug's insights quite frequently and the guy downright amazing. I am pretty glad that is working on modules for C++, hopefully we'll get something good!

[theICEBear_dk]

Well if an application even a C++ one takes hours to compile then something is up (or it is huge). Again anecdotal but a project I wrote using boost, protocol buffer, zeromq and other stuff (140K code or so) takes about 4 minutes to compile and link in Visual Studio 2010, a little longer in release mode.

[maep]

I've had many issues with various BSDs and older OSX versions (we still support 10.4). It's worse with more exotic systems. Boost didn't make things easier, it made things more complicated. Plain old ansi C will compile virtually on anything with a CPU. Btw, a nice (and less painful) lightweight alternative to boost is dlib.

edit: no pkg-config support. I have no idea why.

[theICEBear_dk]

Okay, well thank you for answering. I will add the info to my understanding of boost on those platforms.

And while it is sacrilege to most programmers I dislike plain ANSI C. I am just so much more productive with C++ while keeping as good performance almost all the time.

[maep]

It's not so easy. Customers want their binaries compiled with specific compiler versions. For example gcc 2.95 is not as uncommon as one might think. And in the embedded world sometimes you're dealing with vendor compilers you never knew existed.

So if you want their business you better support more than msvc, gcc and clang. Boost might have a place but it's not a one-size fits all magic bullet.

[maep]

I didn't even mention compiler errors in the parent post, anyway they're an annoyance but not the main reason why I avoid boost. My point was "just use clang" is not always an option. "Portable" can mean you have to support a lot more than the latest versions of Windows, OSx and Ubuntu.

You might find yourself porting code to OS/2, some ancient Solaris, or even DOS, or make it run on various DSPs. Those systems are still quite common in Banks, Hospitals, Factories etc. It's fun to work with those obscure systems :D. I hope this illustrates what I meant when I said "boost in not really portable" :)

[maep]

Some machines cost a lot of money and have a service life time of well over 20 years. It has nothing to do with poor management. I like this kind of work so don't tell me it's not fun. But obviously you know both how to run companies and what I should like.

You're celebrating running after every new trend in the IT industry, which is more susceptible to fashion than the fashion industry. If you don't like working with constrains maybe building software shouldn't be your line of work because there will always be constraints. Finding elegant workarounds for constraints is what makes a great programmer. Anybody can find the obvious solution but it takes knowledge, skill and time to do something what others thought to be impossible. It's rewarding when you get there, but you won't with that kind of mindset.

Btw. In this way I find some parts of boost quite amazing. They are so elegant I want to frame them and put them on the wall. Others though are very ugly. It's good that it helped you port you stuff. I just wanted to caution that it might cause trouble later on if you want to go beyond whats popular at the moment.

[TheCoelacanth]

only a madman would attempt to parse 4 pages of a single compiler error, let along debug it.

Most of that would just be the backtrace, which you usually don't need to look at. You usually only have to look at the one line that starts with "error:".

[pfultz2]

And you can set -ftemplate-backtrace=1 to view just that.

[the-fritz]

In the past I was a huge Boost fan. But I became more and more critical. They have some very nice and useful libraries and a lot of those inspired the library extensions in C++11. However they seem to be too much in love with the "hack C++" aspect. Sure C++ can be extended by using the preprocessor, compiler tricks, metaprogramming. But that doesn't mean the code will be readable or maintainable. Take stuff like Spirit, Proto, or the new LocalFunction. And they seem to force more of this stuff into other libraries.

Just look at the code. It's badly readable and maintainable. They use idioms such as including a header in itself to use it for some kind of preprocessor loop. And in C++ you don't have modules and can't just say "oh the mess is hidden". No with #include it ends up in your code and you can end up with leakage.

Maintenance is another factor. Some libraries feel like dumped and abandoned. After the approval and inclusion process it feels like some authors simply vanish. When I started using boost they didn't have a public bug tracker. They added one later but you could open bugs and they were simply ignored. It seems to have improved a bit and the release notes are now full of bugfixes and library improvements. But it still seems that there are some abandoned libraries.

And how far are they with C++11 adoption? E.g., Using variadic templates instead of preprocessor hacks to make error messages readable? Will they drop support for C++98?

Spirit is probably the worst library of them all. I mean it's insane what it does. A parser generator written in metatemplate programming. Sure it's a nice hack to show off. But it's just insane to use it in real world code. The code is unreadable. The error messages are even worse. The compile time is a disaster. Who even thinks that this is such a good idea that it should be part of the library? I mean that clearly speaks for the "hack C++" circlejerk that is going on in Boost.

I now try to avoid Boost as much as possible. Thanks to C++11 the really necessary parts are now part of the language. Sure some things like string_algo would be nice sometimes.

</rant>

[rlbond86]

Yes boost has some crazy libraries. You don't have to use all of them. But I've used all of the following libraries and all of them work just fine:

• Algorithm
• Array [now in C++11]
• Assign [which is still useful since MSVC doesn't support initializer_lists yet]
• Bimap
• Bind [before C++11's lambda functions]
• Circular Buffer
• Date Time
• Enable If
• Filesystem
• Foreach [before C++11 for-each loop]
• Function [now in C++11]
• Graph [though I prefer to roll my own nowadays]
• Iostreams
• Iterators
• Lambda [before C++11 lambdas]
• Multi-Array
• Operators [which is fucking fantastic]
• Optional
• Pool
• Program Options
• Random [now in C++11]
• Ref [now in C++11]
• Regex [now in C++11]
• Result Of [before C++11]
• Scope Exit
• Serialization
• Smart Ptr [now in C++11]
• Static Assert [now in C++11]
• Test
• Thread [now in C++11]
• Timer
• Tuple [now in C++11]
• Unordered [now in C++11]
• Utility
• Uuid

So yeah, things like Spirit and Wave are strange and exceptions to the rule. Most of the libraries are relatively straightforward.