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."
Boost made one of my cross-platform projects extremely easy to write; wrapping network functions to account for differences between Windows and Linux was not fun.
Almost every modern C++ codebase uses Boost somewhere
[Citation needed]
Boost is created and used by a highly vocal minority of C++ supergeeks. You can play with the definition of "modern", but it's only been in the recent past that Boost even compiled on more than the bleeding edge platforms. Most of the C++ projects I've worked on professionally are still worrying about whether to allow non-trivial use of templates or how to avoid screwing up exceptions, never mind trying to fight through the mess that is getting Boost installed and running these days and spending time getting lawyers to review the licensing terms.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
you'll be missing out, boost fixes lots, I mean LOTS of C++ deficiencies... at a cost of compile times and sometimes bogus compiler errors.
Boost is a great example of what a bloated, backward language C++ has become. It relies on complex intricacies from the standard that are difficult for compiler writers to implement correctly and robustly and without bugs. As a result, Boost itself is not very portable. Either it works on your platform and compiler, or it sort of works, or it doesn't.
Boost--and template metaprogramming in general--is a great exercise in intellectual masturbation. They identified a bunch of useful functionality that isn't supported by the language. Rather than design a new language that does support that functionality, or build external tools to provide it, they contort the template semantics of the language in order to try and squeeze that functionality out of nothing.
Well, template metaprograms are crap. They're nigh undebuggable, they produce unreadable error messages, they take forever to compile, and most C++ programmers don't know how to write (or even read) their implementations. They're an abomination.
Since meta-programming is clearly useful, and something that a lot of programmers want to do... why not add true compile-time metaprogramming support to C++ (or better yet, develop a 10x simpler and cleaner language and put proper compile-time metaprogramming support into it)? Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
Again: Boost exemplifies everything that's wrong with C++. All of the corner-case features of C++ that Boost exploits in order to provide useful and sane functionality in an insane way, should be removed from the language (or its successor). Instead, general and clean and low-level metaprogramming mechanisms should take their place so that the functionality embodied in Boost could be written directly by any mid-level programmer instead of an elite group of template wankers. :P
For a real laugh, read the parent replacing "C++" with "C" and "Boost" with "C++"
doYouLikeThatNamingConventionBetter OrEveThaNamCon?
You just got troll'd!
Seriously. Boost lets you avoid maybe five lines out of every hundred at the lower levels, but that doesn't really improve performance, just make code less readable and more dependent on another library. If people wanna use Boost, fine, but not all "modern C++ codebases" use it or even like it.
~ C.
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?
As a result, Boost itself is not very portable. Either it works on your platform and compiler, or it sort of works, or it doesn't.
If you left this out you would've looked like less of a troll, seriously. Boost compiles with GCC4 (From 4.0.1 to the latest, on Mac, Linux and BSD), Intel's compiler collection (All OSes), Visual C++ (7.1 to 9.0Beta) and Borland.
If it isn't cross-platform enough, I'd like to know what platform and compiler you use
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.
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.
This sig used to be really funny...
Rather than design a new language that does support that functionality, or build external tools to provide it, they contort the template semantics of the language in order to try and squeeze that functionality out of nothing.
Wait - You actually mean to say you'd rather see an entirely new language appear to address mere oversights in an existing one, than extend the single most widely supported (in the sense of "used" and "dev tools exist on platform-X") language to do a few new tricks?
As an aside, I don't use Boost. But if it does what I needed, you can bet the farm I'd use it rather than waiting for Programming-Language-Du-Jour support on a given platform... For a frame of reference, consider the classic comeback to the apologist's "but Java runs on so many platforms" argument: "And how did you compile the JVM?".
I'm seeing tons of comments on this thread about how awful boost is and how all it does is cause global warming, start wars with middle eastern nations, and destroy the pristine beauty of C++. Huh?!?
Yes, boost includes meta programming libraries, but it also provides a number of other useful and relatively basic features which truly are missing in C++. The shared_ptr class is one example that nobody thought to include in STL for some unclear reason. What if you want non-platform specific threading or date/time functions?
If you aren't using boost, that's fine, but it is as excellent of a general purpose C++ library as we have available today.
Affecting the quality? Obviously not, but I won't stop you for being silly to try to make a point.
I'm seeing a release blurb which looks more like an abbreviated commercial press release - including the mandatory "we're the market leader" claim - for a pretty uninteresting update. While this sort of stuff weasels its way into slashdot every now and then, the whacked out of reality claims definitely raises the bullshit-o-meter alarm.
Allow me to demonstrate using the "Almost every modern uses somewhere" template:
"Almost every modern streaming video server uses Windows Media Technologies somewhere"
"Almost every modern web server uses PHP somewhere"
"Almost every modern web design firm uses Dreamweaver somewhere"
Do these claims affect the quality of whatever technology they're trying to push? No. Are the statements obviously overreaching? Yes. Does the fact that the recommendation (assuming they're attached to one in the first place) both push a product/tech and try to convince me that "it Must be Good since So Many Others use it (especially if they're 'modern')" make me less inclined to buy into the pitch? Oh yes.
YMMV, of course.
Well, template metaprograms are crap. They're nigh undebuggable, they produce unreadable error messages, they take forever to compile, and most C++ programmers don't know how to write (or even read) their implementations. They're an abomination.
Since meta-programming is clearly useful, and something that a lot of programmers want to do... why not add true compile-time metaprogramming support to C++ (or better yet, develop a 10x simpler and cleaner language and put proper compile-time metaprogramming support into it)? Templates are not a natural way to express metaprograms. Why not give C++ programmers the tools to write nice, clean, object-oriented, imperative metaprograms instead of the kludgy functional metaprograms they are forced to scrape by with now?
This isn't proof that template metaprogramming or even the boost implementation of it sucks. This is proof that you've seen some bad code written with that feature. So what? Get in line! I've seen rotten code written using too many macros, I've seen rotten code written using too many templates, I've seen rotten code written using too many classes.
Basically, name a language feature, find some engineer who decides that feature is the final greatest achievement in programming, and then give him a year or so. He'll produce some awful, unreadable, undebuggable code.
Personally, I find boost quite useful, and I have never used it to write template metaprograms (it has other features as well). I think they are cool, but I just haven't run into anything where I needed that kind of performance boost.
Why is it that all the trolls are modded up? People that think that Boost is the same as STL are insightful. People that think Boost is for C++ supergeeks are insightful. People that think Boost epitomizes what is wrong about C++ are insightful. Boost represents a serious set of genius level code and design and helps thousands of programmers that understand how good it is.
I understand that trolls exist and that they will always be with us. I understand that ignorant people will continue to post until the end of time. What I don't understand is that the /. community apparently agrees with them. This is supposed to be a community of hard-core geekery that understand things like operating systems, and game programming, and the intricacies of complex, multi-paradigm languages likes C++. What I'm seeing here is that it's populated, in greater numbers, with ignorance and "I heard a sound bite from someone who doesn't know what they're talking about so now I know everything" kinds of people.
Have a look at what you know and what you don't know and then think about how intelligent your opinion actually is, and then post. And when you're modding that post, do the same thing.
This sig used to be really funny...
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.
That's PascalCase. This is camelCase.
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.
Sam ty sig.
And when using C++ [to write games], I don't need: regexps
Not even for parsing your game's preference file?
signals and slots
Not even for notifying game objects that things have happened to other objects?
smart pointers (Seriously? You can't check pointers yourself?)
Not even for disposing of a mesh and texture once no nearby game objects need it anymore?
Boost is not a "template metaprogramming" library, as you seem to be implying. It's just a good library that happens to use template techniques for some purposes for which it is very well suited, for example, the Spirit parser.
You don't need to know template metaprogramming at all to use Spirit. In fact, what Spirit does is make the specification of parsers look like BNF but in C++ syntax. Internally, yeah, the library is awfully complex. But that is the point of a library - it implements once and for all difficult things so that library user's lives are easier. And boost achieves that goal nicely.
Did you even read the link you posted?
Yes I did. The main terms are UpperCamelCase and lowerCamelCase. CamelCase is for for both. PascalCase is just another word for UpperCamelCase.
But I guess one can argue about the finer points for ever.
Martin
I iNsist oN tHe rIght tO uSe zAmbinian cAmel cAse.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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? :)
Of Code And Men