Slashdot Mirror
Boost 1.36 Released
AndrewStephens writes "Good news for C++ programmers: Boost 1.36 has been released with 4 new libraries (including very useful exception templates) and a host of updates. In particular, boost.asio (the cross platform AsyncIO library) has seen major additions and now supports asynchronous disk operations on Windows. Almost every modern C++ codebase uses Boost somewhere, and many of its features find their way into the official language specifications."
A statement on /. makes you less inclined to look at a set of C++ libraries, I'm not quite sure how that logic works, has the statement made on /. somehow affected the quality of the libraries?
The main drawback of metaprogramming via preprocessor is the same as metaprogramming via any external tool--lack of introspection.
What you want is metacode that can be embedded in your normal C++ code, read by the C++ compiler, and can run with access to the AST or some other high-level representation of what the compiler has parsed. It should be able to read, interpret and modify the declarations that have already been parsed--generating new methods or typedefs on the fly, for example.
The compiler knows things about your code: The sizes and alignment requirement of types, the offset of members, whether methods with a particular signature resolve or not, etc.
Rather than funky template metaprograms which try to deduce these things by exploiting strange corner cases of the C++ standard, it would be nice if the metaprograms ran in a context where they had access to all of this information directly from the C++ compiler. It would be nice if the output of the metaprogram was source-code, too. (Much easier to debug that way, than by relying on obscure and cryptic error messages ala C++ templates). ..Of course, C++ is far too big and complicated for this to be done in a sane way. A much better bet is to design a new, smaller, cleaner language (aiming to have perhaps 10% of the complexity and 90% of the usefulness of C++). While you're adding metaprogramming in there, make some room for symbolic includes and a fast and robust incremental compilation system too. The textual includes of C and C++ are so backward its not even funny.
I think the problem a lot of people have with Boost is not related to how good/bad it is; but rather the complexity in understanding it, and the level of complexity that it brings to your program.
The problem as I see it is that if you're not one of the scary smart people that understands the way the boost developers think, then you will have problems integrating boost into your project, and debugging it when things go wrong.
A lot of those problems will be due to your own ignorance but at the end of the day if something isn't obvious or at least well documented (and boost documentation isn't exactly a light read at the best of times) people will be turned off by how difficult it is, no matter how useful or speedy or good or whatever.
I work with a scary smart C++ programmer who swears by boost. I primarily code in C, but he convinced me to write a project using C++ and boost to see how thoroughly useful it is.
With boost, you can in very few lines of code, write code that can do impressive stuff. This is very true. But what you don't realise when you start out is that when you include boost::asio or boost::threads or whatever, you're including hundreds of thousands of lines of other people's code into your program, perhaps unnecessarily complicating it and making it so when you have a problem, you'll be staring at the debugger going "my code failed where?!" with a backtrace stretching back to infinity (and making Java Exception backtraces look NICE).
Yes, reinventing the wheel is a bad thing, and should be discouraged. But what if you just need a simple wheel? A wheel that, I don't know, goes around and around. I don't need it to report on its air pressure, or self repair, or sprout wings and fly if I go off a cliff. I just need it to be .. a wheel.
And boost tries to be the best possible wheel for every occasion. Its the wheel designed by the Borg. Assembled by nanites, it itself is made from nanits and will, whether you like it or not, assimilate your program into the Borg.
I use C++ and Boost and like them. But it's a love-hate relationship. I mostly found the trolls to be insightful because they reflected that love-hate.
C++ is a great programming language in the sense that English is a great natural language. Undesigned, piecemeal, weird idioms, and a pig to learn. But expressive, powerful, portable. Boost plays the role of "the King's English" -- it's a style guide. Sometimes arguable, sometimes wrong, but mostly very good at pointing out how to avoid deficiencies in the language. C, C#, Delphi, Objective C, OCaml, Mathematica and Python are unquestionably better languages than C++. And Esperanto is better than English. But I speak English and use C++ because it does what I need it to do better than any of the alternatives.
Dealing with geeks is a problem for management to deal with. C++ is probably rightly the domain of ubergeeks. If you choose to use C++ because it suits your needs and your geeks like a bit of mental masturbation, good for you. No matter what language you use, your local geeks will push the boundaries. With C++, Boost mitigates the damage your geeks might cause when pushing boundaries (e.g. template metaprogramming). Boost is therefore a tool for managing geeks.
The biggest problem with C++ and Boost is also their biggest asset. The language is too plastic. Every new library, object or template comes with a domain-specific-language that you just have to learn. For example, using functors to create threads. That is counter-intuitive and hard. But with Boost, each domain-specific-language tends to be well designed, so that if you understand C++, then Boost will push you into using the features in a way that is portable and safe.
But an overwhelming gripe is that the online documentation is atrocious. In the sense of incomplete, unclear, impenetrable, useless examples, broken links, broken HTML, outdated. To the point where it becomes a good reason not to use Boost.