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."
Re:Use of Boost? (Score:3, Informative)
While I agree that it's a bit pissy to imply that if you're not using boost in your c++ project, you're not 'modern', neither installation nor license ought to be much of an issue. The license is as clear cut as it can be:
C'mon, that ought to be pretty straight forward, even for a lawyer.
It's been a while since I checked out a new version, but most of Boost didn't need installation since it's mostly include files with templates. You just put them somewhere and include them. Now, there are some libraries (regexp iirc) that need to be compiled, but it builds out of the box on gcc for me.
Re:Slight exaggeration? (Score:5, Informative)
Re:I've never used it (Score:5, Informative)
A lot of the other nay-sayers appear to be just useless trolls. You don't, so I'm going to reply.
You're really selling boost and, by derivation, yourself short. Boost makes a ton of things simple and robust. I wrote the following, cross platform C++ code with boost:
C++ is old and that means that it doesn't have anything like a modern language has. What it's missing, Boost fills in (not completely, mind you, but it does a really good job). With C++ you get speed and controllable code (C# runs a close second, but I still wouldn't write an OS in it), and with Boost you get a ton of ease back in the language as well.
You're doing yourself a serious disservice by not looking into it. The one thing that I can't believe is that you really did look into it, and certainly not twice. If you did, you'd know it's not just a source of "template tricks"... far, far, far from it.
If you're not using boost, I can guarantee you're reinventing the wheel... badly.
Re:Huh. I'm still using STL. (Score:3, Informative)
Hey, anyone else ever notice that games are, generally speaking, the buggiest, hackiest, most insecure pieces of software on a system? Other than spyware and "enterprisey" stuff, anyway.
- smart pointers (Seriously? You can't check pointers yourself?)
No, I can't, and neither can you unless you've found some way to replace your organic brain with a metal and wire positronic supercomputing device. Once you've managed that feat, you still have to overcome the impossibility of using exceptions properly without RAII. Stick to games.
Re:Boost epitomizes everything that is wrong with (Score:3, Informative)
Boost targets implementations which actually implement the C++ standard, not subsets of the standard for embedded purposes. The whole point of Boost's advanced functionality is that templates are the only way to express it in C++, short of implementing an actual metalanguage on top of C++, which would be even more heavyweight and incompatible.
Re:Boost epitomizes everything that is wrong with (Score:3, Informative)
I've given you two keywords (restrict, export) and two features (implicit functions, inlining) that aren't well implemented (okay, lets say different enough so that one code might not be compatible) across the mainstream compilers, but I'll tell you another one: template metaprogramming and typename.
I don't know about the state of VC2008 and Comeau since I've stopped working with them a while ago (working on OSX with intelc and g++), but I remember by my young self having a lot of difficulties building cross-compiler expression templates and dynamic type resolution libraries. I'm not talking export here, just using templates of templates to build expressions that should be inlined correctly at the end of the compiler pipeline. If it's compiled at all.
I won't find a real world code example, lets just say that when you enter the templates recursion, template operators and heavy template worlds, and you throw in some functors, binding and dynamic typeinfo (which are all standards, not some unsupported feature like export), what works on one compiler will choke the next one. I've had my share of "Internal Compiler Error". Those are nasty and almost impossible to resolve. And sometimes G++ just give up without an error code... oO
Saying that what works on one mainstream compiler should work on the other if you follow standard is the same as saying that coding POSIX guarantees you to work on all mainstream operating system. Theory is fine, practice showed us otherwise.
And boost came across these problems as well. Do you think the HEAVY use of macros and preprocessing is only there to render the code unreadable? :)