Boost 1.36 Released 166
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."
Really appreciate it (Score:2, Interesting)
Re:Boost epitomizes everything that is wrong with (Score:1, Interesting)
Back in my day, we did metaprogramming the way god intended -- in the preprocessor, with recursive includes.
Re:Slight exaggeration? (Score:4, Interesting)
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 thing missing, is introspection (Score:3, Interesting)
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.
Re:Huh. I'm still using STL. (Score:3, Interesting)
Soo, what happens to your game in case of an exception then? Always careful to clean up any allocated resources I assume? See, this is not a contest to see who can "handle" cleaning up memory himself. Any monkey can do manual resource management if he wants to. Personally, I just can't be arsed to twiddle pointers and exposing myself to memory leaks and other problems unless I have to. Not that I use manual memory allocation much at all.
Anyway, my hobbyist game framework contains at least 4 of the features you mentioned (How on earth do you manage to make a game without having at least one graph in there?), and I'm damned thankful I didn't have to write the boring implementation details myself.
Re:Are we talking about the same library? (Score:4, Interesting)
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.
Boost is a mixed bag (Score:5, Interesting)
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.
Re:Use of Boost? (Score:1, Interesting)
take a look at stackless python:
http://www.stackless.com/
Re:Use of Boost? (Score:3, Interesting)
Anyone who had seen Boost source code knows that there are plenty of old hacks and workarounds in it specifically to make it work (to some documented extent) on such archaic compilers as VC6 and g++ 2.95.
Sure, but those are by far the biggest targets. How many little hacks were in there to support the native compilers on IBM, Sun or HP workstations, or even older Macs before GCC took off there?
Sounds like the kind of people who might be surprised that C++ is already out of draft for some time, then.
You judge too quickly. The problem isn't a lack of understanding; some of the people I'm thinking of are among the smartest C++ hackers I've ever met, the kind of people who have been following the C++ newsgroups since some way back into the last century, been to their fair share of ACCU conferences, even filed the odd defect report against the C++ standard. Rather, the problem is that what the standard says and what was actually portable without excessive effort across a wide range of compilers were worlds apart for such a long time (and I don't just mean export).
Oh, and I wonder - how do you "screw up exceptions"?
That's worth at least a blog post, if not a book, but I'm certainly not thinking of forgetting to enforce pairing of new and delete if that's what you're assuming.
For one thing, this is a prime example of varying compiler support. Techniques are known for implementing exceptions with almost zero overhead unless they are actually thrown. However, those techniques have only been implemented in compilers relatively recently, and as usual the big names have been better at it for the most part.
Then there's the little issue of retrofitting: techniques for working safely with exceptions weren't well known when the feature first became available, and a lot of projects got stung and then avoided them. That may have been a poor choice with hindsight, but retrofitting exceptions onto an existing project that wasn't written with them in mind is challenging, to say that least.
And then of course, there's the fact that it's not always as simple as RAII in C++: there was some discussion on another forum recently about the sanity (or lack thereof) in the popping from a stack problem in C++, for example.
Re:Boost epitomizes everything that is wrong with (Score:1, Interesting)
Either it works on your platform and compiler, or it sort of works, or it doesn't.
I find that to be the case with all software, everywhere.