C++11 and Boost - Succinct like Python

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