Weekly Edition
Return to the Development page
| |||||||||||||
The Boost C++ Libraries
Whatever type of software you develop, there probably exists an
open-source C++ library that can help you avoid re-inventing the wheel.
However, C++ offers no
analog of Perl's CPAN or Java's extensive environment, so it can be
difficult to find code of sufficiently high quality which can be easily
integrated with code from other sources. In recent years, the Boost C++
Libraries have become the place where a C++ developer should look first
when seeking quality open-source C++ components.
The Boost C++ Libraries provide components that can be employed in just about every development project. Boost libraries are among the most powerful and portable components in the world of C++ development. Whereas the quality of open-source code is often an unknown quantity, the standard of code distributed in the Boost distribution is remarkably high, owing to the extensive peer review process required to accept libraries into the distribution. Each library in the Boost distribution has been reviewed by the Boost developers and accepted through an open voting process, ensuring a consistently high level of quality, and an adherence to principles of the C++ community. Boost libraries are designed to work well with the C++ Standard Library, and other libraries designed around the principles embodied in the Standard Library. Boost libraries are loosely-coupled, and designed so that you can use only what you need, without trying to provide an all-encompassing environment. Boost libraries are all released under the Boost Software License, an extremely permissive license which is designed to make the libraries equally useful to commercial and non-commercial developers. The Boost Software License is very similar to the MIT License, with the major difference that object code derived from Boost-licensed source code can be redistributed without the reproduction of copyright messages. This is required to permit all developers to use Boost libraries in all of their code, without concern over eventual distribution requirements. The current version of the Boost Libraries is Version 1.33.1, released on December 5, 2005. It contains 63 libraries to assist C++ developers. Many of these libraries are useful in a broad range of application development, such as the threads library, the regular expression library, the portable filesystem library and the smart-pointer library. Other Boost libraries help to make C++ a more expressive and productive language in which to develop. These libraries include the generalized function and bind facilities, the signals library and support for named (rather than positional) function arguments. Finally, Boost also contains libraries that are designed to help C++ developers improve their own libraries; examples include the concept-checking library, the unit testing library, the library for developing iterators and that for accessing type traits. Perhaps the best reason to use Boost, however, is because of its contribution to the C++ Standard Library: using the Boost libraries today is a foretaste of the next C++ Standard Library revision. The C++ standards committee favor the standardization of proposals that have proven their worth in real-world use. Boost is an ideal proving ground for such proposals, and this has been demonstrated in the Proposed Draft Technical Report on C++ Library extensions (PDF), known as 'TR1', the first specification of likely additions to the next C++ standard. Ten of the fourteen included proposals were implemented first as Boost libraries, and proven mature and robust in the Boost distribution. Other Boost libraries have been proposed for acceptance into the next Technical Report ('TR2'), open until October 1, 2006. Boost development is ongoing, you can participate by joining the mailing list for development, or the boost-users mailing list to discuss using the Boost libraries in your development work. (Log in to post comments)
lambda functions Posted Dec 8, 2005 10:03 UTC (Thu) by pkolloch (guest, #21709) [Link] One of the very impressive features are lambda functions (IMHO):
for_each(a.begin(), a.end(), std::cout << _1 << ' ');
"std::cout << _1 << ' '" defines lambda function object taking one parameter.
Unfortunately, one cannot totally freely define those. Correct me, if I am wrong, but the following should not be possible:
for_each(a.begin(), a.end(), std::cout << "blupps: " << _1 << ' ');
The "<<" is evaluated from left to right. That means that std:cout << "blupps: " is evaluated before the special magic _1 can interfere and "blupps: " is printed immediately. (there is some special function to make this possible, I do not remember)
Functional conditional statements like "if_then" etc. are also provided for usage inside of lambda functions.
lambda functions Posted Dec 8, 2005 11:22 UTC (Thu) by mvogt (guest, #34379) [Link] There is a special function; you can use
for_each(a.begin(), a.end(), std::cout << constant("blups:") << _1 << constant(' '));
to defer evaluation of the insertion operators until the lambda function is invoked. (You don't need the second 'constant' really; it will be deduced.)
There is also a 'var' function for deferring modifiable variables.
lambda functions Posted Dec 8, 2005 20:03 UTC (Thu) by rmstar (guest, #3672) [Link] If you have time one day, it might be worthwile to look at how thesethings work in a language where such features are natural. The boost lambda facility is a genuine crock.
lambda functions Posted Dec 8, 2005 22:02 UTC (Thu) by ncm (subscriber, #165) [Link] The point is not how pretty it is (although it's remarkable how well they've done), but rather that it was possible to do this entirely in the library. In practical terms, it means that Boost's lambda library makes advanced techniques available for use in an industrially useful language.
It's easy to build fancy features into the core of a toy language. It's hard to make a language powerful enough not to need fancy features coded in its core. In a very real sense, any directly-useful core-language feature that doesn't map to a machine instruction or two indicates a language design failure: the language isn't up to the job of letting a user express the feature using the primitives provided. In that sense, for example, LISP's CONS/CAR/CDR, not to mention the garbage collection they imply, indicate fundamental failures. Most languages taken seriously in academia repeat LISP's failures, which suffices to explain why they are not taken seriously in industry, and why there is *still* no credible alternative to C++ for industrial use.
If this sounds like an indictment of academic Computer Science, you read it right.
lambda functions Posted Dec 8, 2005 22:24 UTC (Thu) by mvogt (guest, #34379) [Link] I think that Boost and similar library projects have gone a long way to finding the current practical limits of library-based development in C++. This is important because it has given a much better indication of what language changes are required to continue moving forward.
If you read through the language change proposals for C++0x, a lot of them address cases where the current system has been found to run up against its limits. And for those who find the current templates-plus-overloading-plus-inheritance mechanisms too inelegant, Daveed Vandevoorde's Metacode proposal is a possible way this will be rationalised in a future language revision.
I won't touch your LISP... criticism... but I agree that there's no credible alternative to C++ for many industrial purposes. Where I think C++ shines especially, is the ability to do extremely low-level tasks, but to wrap those tasks in useful higher layer abstractions.
A good example of this would be the Spirit library (distributed in Boost), which wraps extremely low-level character-by-character text processing, into a syntax which is very similar to directly coding EBNF.
lambda functions Posted Dec 9, 2005 1:49 UTC (Fri) by ncm (subscriber, #165) [Link] It takes nothing away from LISP or its originators to identify its flaws, in hindsight. LISP is not only fifty years old, it is based on a design never meant to be implemented! How much was understood, back then, about software engineering? Clearly the only fault is in those who have failed to learn from the mistakes, over and over again. Over the decades since, academic toy languages have incorporated many important ideas that ought to be more readily available to engineers, but are too often tangled up with those fifty-year-old mistakes. The Boost crew deserve Turing awards for teasing out many of the good ideas and putting them into a useful library.
The lack of a credible industrial alternative to C++ isn't just bad luck. It is incontrovertible proof of systematic failure, over decades, by those responsible for evaluating language designs.
By the way, the expressions "low-level" and "high-level", in my experience, are readily abused to prejudice discussion. Most usually this means disparaging concerns for performance and trying to distract the reader from fundamental inefficiencies. I'm not accusing Mr. Vogt of such usage. Rather, I'm pointing out that the words have acquired very slippery meanings, so that their use often obscures more than it reveals.
lambda functions Posted Dec 17, 2005 20:06 UTC (Sat) by renox (subscriber, #23785) [Link] While I agree that languages usually do too much, C++ is not the solution:1) the code used in Boost or other similar library is so complex that some compilers wouldn't compile it 2) those library are unreadable 3) sometimes this complexity cannot be hidden to the users which makes ugly code..
Have you looked at Scala? I think that this language is a step in the right direction for this part, unfortunately it is only for JVM or .Net no native compilation currently.
lambda functions Posted Dec 9, 2005 6:00 UTC (Fri) by dvdeug (subscriber, #10998) [Link] What do you mean there's no alternative to C++ for industrial use? What ever happened to the billions of lines of code in Fortran, Cobol, Java, Perl, PHP (industry uses the web just like everyone else), Python, Bourne Shell, Awk, JCL, Forth, BASIC, Visual Basic and yes, even Lisp?
When you say that "any directly-useful core-language feature that doesn't map to a machine instruction or two indicates a language design failure", do you really consider shell, make, Perl or python failed languages, which should be forgotten in favor of C++?
lambda functions Posted Dec 9, 2005 8:17 UTC (Fri) by ncm (subscriber, #165) [Link] We're not discussing scripting languages. You don't use a garden tractor in a mine, however handy it might be in the back yard. A Skil saw is of little value when you're building a jetliner.
FORTRAN, COBOL, and (yes) FORTH are almost as old as LISP. Even in their modernesque forms they implement no concepts more recent than the '70s. You omitted assembly language.
lambda functions Posted Dec 9, 2005 9:08 UTC (Fri) by khim (subscriber, #9252) [Link] Yes, it's very true that C, FORTRAN, COBOL and even Java/C# do not include a lot of modern ideas. The fact of the matter is: they are used more often by "industry" then C++. C++ has it's place but the only reason it's used at all are few good (and few not-so-good) toolkits: Qt, MFC, ATL, etc. In last 10 years I was involved in many projects and only tiny part was written in C++ - mostly things for Windows (Microsoft only recently switched away from C++). While what you said is true (different languages are suitable for different purposes) it all looks to me like try to define "industrial use" in such a way as to make C++ winner. Let's define "industrial use" as "something done by big boys". What ? They are using scripting laguages. Ok - let's explicitly exclude them. Oops - still no win: huge number of things is done in C or FORTRAN ? Let's say that "ancient laguages" are not of concern. Still C++ is not winner ? Ok - let's ignore VM-based laguages as well. And so on. In the end you'll define some niche where C++ is clear leader - but this can be done for almost any language. Even very obscure langauges.
lambda functions Posted Dec 9, 2005 18:43 UTC (Fri) by ncm (subscriber, #165) [Link] C++ is not a niche language. Webpage support is not, as a rule, an industrial use (although web interfaces occasionally appear in industrial settings). GUI coding, likewise, is not an industrial use.
Any language suffices for easy problems. Hard problems demand range. If you confine yourself to easy problems, you won't notice the built-in limits of your language. When you do need the range, minor inconveniences are easy to overlook.
Of course most problems are easy, and most people spend their time solving easy problems. It's generally not hard to ignore the hard problems, and the people working on them.
lambda functions Posted Dec 9, 2005 21:25 UTC (Fri) by dvdeug (subscriber, #10998) [Link] Writing an application as quickly as possible is not an easy job, yet it's one that Visual Basic makes easy. Solving complex problems of logical inference is not an easy job, but it's one that PROLOG and similar logical languages make easy. Writing an expandable editor like EMACS is not easy, but it's one that LISP makes easier. Writing a webpage generator isn't that hard, but it's a lot easier in Perl than C++.
C++ has less range than Common Lisp. If you demand that all core language features "map to a machine instruction or two", what more can you expect?
It's seriously absurd to dismiss all problems besides "industrial" problems as easy. There's no challenge to writing a paycheck generator. There's challenge to writing code to control a 757 (code written in Ada, BTW), but it's not in the range; it's in getting things done, always exactly correct, on a very tight time schedule.
A game is not a trivial thing; it's funny that many game programmers either refuse to use C++ for speed reasons, or use scripting languages to control much of the game's actions. Obviously, C++ doesn't provide the right range for them.
C++ Game development Posted Dec 10, 2005 6:03 UTC (Sat) by mvogt (guest, #34379) [Link] I disagree with your assertion that C++ is not used for games for performance reasons. I think commercial games are very often written in C++.
If you look at sourceforge, two categories I sampled as having high-performance requirements (simulations and first-person shooters) have more than half of their listed projects listed with C++ as a development language.
C++ can be used with almost no abstraction penalty over C, depending on what features you choose to employ. There is a good document establishing the efficiency costs of various C++ features available at http://www.research.att.com/~bs/Performance-TR.pdf
I agree that many games have a component written in scripting languages; I think that this is probably a reflection of the rapid time-to-market pressure in the game market as much as anything else.
C++ Game development Posted Dec 10, 2005 7:32 UTC (Sat) by dvdeug (subscriber, #10998) [Link] But rapid time-to-market is something that makes a problem hard, and there's no reason to dismiss languages that are ideal for solving such hard problems as unworthy of study.
C++ Game development Posted Dec 10, 2005 8:22 UTC (Sat) by mvogt (guest, #34379) [Link] Of course such languages should not be dismissed, but nor should they be espoused for tasks they're not designed for.
Ideally, C++ can be used together with a language designed for embedding (such as Lua) for game development.
That said, games are an unusual domain, where even correctness can be less important than performance or speed-to-market.
C++ Game development Posted Dec 10, 2005 8:53 UTC (Sat) by dvdeug (subscriber, #10998) [Link] Since when is correctness taking second place to performance and speed-to-market unusual? C++ itself puts correctness second to performance in relegating bounded arrays to the library. If you put correctness first, you would use the SPARK programming language, or something similar, and never release unless every possible test has been passed. But in reality, virtually every program releases with known bugs, frequently major ones. Jon Bentley mentions in one of the Programming Pearls books that given a 10x speed improvement on his typesetting system or all the bugs fixed, that he would have taken the speed up. If you (believably) made the offer on the GCC list, I suspect the list would blow up in a flame war over the issue.
C++ Game development Posted Dec 10, 2005 22:05 UTC (Sat) by mvogt (guest, #34379) [Link] Fair enough, there are obviously application domains where approximations are acceptable, and those where they are not. What would be the point of a 'grep' that returned most matches, or a 'find' with false positives?
C++ does not put correctness second to performance, it ensures that you needn't pay for what you don't use. (Ignoring legacy C built-in arrays,) if you can guarantee array bounds will not be violated you can use the subscript operator for unchecked access; you can use the 'at' member function to get runtime checking where desirable. 'Relegating... to the library' has been the favoured C++ evolution strategy, for right or wrong. It doesn't indicate that something is less correct or important.
I will admit that C++ puts guranateed correctness second to pragmatism. Languages that don't have not been conspicuously successful in general purpose programming.
lambda functions Posted Dec 9, 2005 21:07 UTC (Fri) by dvdeug (subscriber, #10998) [Link] So if you redefine industrial use as not to include "scripting" languages and not to include "web" languages and not Visual Basic, and exclude languages much more than 20 years old, then your statement might be true. But how is that an indictment of academia? Why should academia care only about your subset of the real world usage?
Modern Fortran supports object-orientation and exception handling. If modern Fortran supports no concepts more recent than the 70s, I'm curious what features of C++ are more recent than the 70s?
Recent features of programming languages Posted Dec 10, 2005 5:49 UTC (Sat) by mvogt (guest, #34379) [Link] Well, all ideas are old, of course, but the feature that separates C++ from its closest peers (probably Ada, Eiffel, Objective-C) is the support for compile-time metaprogramming.
It's certainly not elegant, and was almost accidental in its design, but it combines very well with C++'s don't-pay-for-what-you-don't-use philosophy, and its ability to adjust its interface through operator overloading.
But, the point that these are all old ideas is valid. Their age probably indicates the amount of time and experience required to get a community of implementors and developers to assimilate a set of ideas.
lambda functions Posted Dec 10, 2005 8:28 UTC (Sat) by ncm (subscriber, #165) [Link] None of those scripting languages, nor "web languages", nor Visual Basic came from academia. For that matter, neither did FORTRAN or COBOL. Most have been reviled by academia, for generally good reasons. The various LISPs, Prologs, Haskell, the MLs, and suchlike have largely failed to escape academia, also for good reasons. Industry briefly flirted with Algol, Pascal, Ada, and their ilk, as well as Smalltalk, and then largely abandoned them, again for good reasons.
C++, in its original conception, supported one important new concept: the destructor. Languages conceived since have failed to adopt it, limiting the effectiveness of their exception handling, and the languages' industrial usefulness. (No, "finalize" doesn't help.)
Later additions, particularly templates in the form standardized by ISO, enabled STL, Boost, and a constellation of matrix- and signal-processing libraries that outperform languages specialized for the purpose. Only CAML has matched C++'s capability to define fast, powerful libraries, but often cannot be used industrially because of its limited support for resource management.
Object orientation has turned out not to be nearly so important as the '90s hype machine suggested. Languages designed to the hypesters' criteria have turned out peculiarly limited.
Why should academia care about industrial usefulness? Arguably, no reason; certainly academic art and literary criticism have precious little to do with actual art or literature. However, an academic who cares to avoid sterility and irrelevance must confront fundamentally hard, large real-world problems. Such problems are, by their nature, not limited to conveniently proscribed domains. Tools to address them must be equally well prepared for bit twiddling, lambda calculus, hard-core numerics, real-time hardware resource management, fancy data structures, and what-have-you. Academic CS department hostility to serious engineering needs leaves its graduates ill-prepared to contribute.
lambda functions Posted Dec 10, 2005 8:46 UTC (Sat) by dvdeug (subscriber, #10998) [Link] Most concepts embedded in C++ were originally developed in academic languages. It's not always about the languages academia developed; it's about how they influenced the languages that everyone uses.
Once again, your definition of industrial usefulness ignores most real-life problems. A huge number of computer people run servers; they may not touch a compiled language for years on end, but write and edit in scripting languages all day long. Or they may maintain websites or write Java games to be played on line, or program off-line games in Python, like Civ 4. Not every real life problem is to be tackled with C++.
lambda functions Posted Dec 10, 2005 10:21 UTC (Sat) by ncm (subscriber, #165) [Link] As I said, most problems are easy. Actually, most hard problems don't involve any coding whatsoever.
You don't learn much from solving the same easy problem over and over, or even from solving lots of easy problems. Hard problems teach deep lessons, if you can bring yourself to pay attention. A problem that was impossible to solve until you invented something new is more precious than any book.
Design failure ? Yes - C++ is a design failure Posted Dec 9, 2005 9:06 UTC (Fri) by khim (subscriber, #9252) [Link] It's hard to make a language powerful enough not to need fancy features coded in its core. In a very real sense, any directly-useful core-language feature that doesn't map to a machine instruction or two indicates a language design failure May be. But if you truly believe this then try to count number of machine instruction for single line cited above. Gosh. Even pointer assignment in C++ is quite non-trivial operation if youll take a look on machine instructions generated. If you really want language close to machine - you'll take C. If you need language with powerfull features - you'll take LISP, if you need "boss-approved" language - you'll take C++. C++ is all hype and marketing, really...
Design failure ? Posted Dec 10, 2005 5:40 UTC (Sat) by ncm (subscriber, #165) [Link] Ignorance must be a very comfy place, to make one so reluctant to leave it. One can never be lonely there.
lambda functions Posted Dec 13, 2005 22:26 UTC (Tue) by pimlott (guest, #1535) [Link] The point is not how pretty it is (although it's remarkable how well they've done), but rather that it was possible to do this entirely in the library. In practical terms, it means that Boost's lambda library makes advanced techniques available for use in an industrially useful language.... in a limited, difficult to use, and unreliable form. But at least it makes C++ slightly less painful. It's hard to make a language powerful enough not to need fancy features coded in its core.You consider lambda a fancy feature, but you don't consider multiple inheritance or the rules for implicit type conversion and copy constructors and overloading fancy features? That's a skewed perspective. any directly-useful core-language feature that doesn't map to a machine instruction or two indicates a language design failureThat's an arbitrary standard (especially as CONS, CAR, and CDR map to machine instructions on some processors). At most, it matters to a tiny fraction of programs. You already acknowledged that OCaml has performance on par with C++ despite not mapping directly to machine code (and despite many fewer people working on OCaml compilers). .Most languages taken seriously in academia repeat LISP's failures, which suffices to explain why they are not taken seriously in industry, and why there is *still* no credible alternative to C++ for industrial use.Come on--this is an industry that is terrified by new ideas (unless they're old ideas reintroduced with some new buzzword). C++ owes its current status to momentum and widespread support, not to any intrinsic quality. Companies that have used "academic" languages for "industrial use" have been quite successful.
lambda functions Posted Dec 13, 2005 23:36 UTC (Tue) by ncm (subscriber, #165) [Link] Inheritance (of whatever variety) and automatic conversions certainly are "fancy features". They don't belong in the core of a language. A language more powerful than C++, and less encumbered with legacy compatibility, would have them in the standard library. Lambda is hardly a feature at all -- it's a notational detail -- and probably *does* belong in the core language.
By "directly useful", I mean operations that actually perform computation, resource management, control flow, and I/O, as opposed to primitives that organize code (e.g. types). Everybody's long since conceded that I/O belongs in the library. That was a radical notion until C thrashed Pascal. Threads were supposed to be built in, too, until C thrashed Ada too. Progress in language design lies in discovering that apparatus previously considered indispensable amounts to trivial applications of a more powerful core primitive.
CONS may be one or two instructions, but CONS implies garbage collection, which is enormously more intrusive than Ada's failed built-in threads. The presence of CONS in the core language concedes that the language is incapable of coding resource management as a library facility. GC is actually worse than that: even if the language is otherwise up to the job, GC interferes so as to make it impossible anyhow.
The MLs are almost expressive enough to take on C++, but are encumbered with too many of LISP's fundamental mistakes.
The belief that C++ was a shoe-in, and is now thoroughly entrenched, is the most pathetic sort of sour grapes. C, in the 80s, and now C++, got used because they have proven useful and usable where they are needed. Academic languages aren't used precisely because they have turned out not to be so. Instead of whining about industry's supposedly dogged conservatism, try rethinking your own dogmas. That's what science and engineering are all about: when experience says your idea is wrong, reject the idea, not the experience.
The world needs a language more powerful and cleaner than C++. It won't be built by people who can't even understand why C++ succeeds, or why its academic competitors have failed over and over again.
Companies that have used academic languages successfully have either used them as fancy scripting languages (e.g. Yahoo stores) or depend heavily on calling out to libraries coded in an industrial language (e.g. ITA Software). LISPies like to say that Python and Ruby are really just dressed up LISP, but they're wrong: LISP is really just stripped-down Python.
lambda functions Posted Dec 14, 2005 2:26 UTC (Wed) by pimlott (guest, #1535) [Link] Ok, I took your previous post as anti-lambda and pro-everything-in-C++, which was clearly mistaken. I absolutely agree that a language should be built on a minimal set of primitives, but I strongly disagree that they need be close to the machine.
I'm not sure why you say that CONS implies garbage collection; there could be free-cons. Your suggestion that memory management should be in a library is plausible for many languages; however, GC seems to be required for pure (or mostly pure, as in ML) functional languages, so in these cases GC must be in the core. Funtional languages usually have special constructs or a library for manually managing memory, when required. "GC makes it impossible" seems extreme to me.
Re "sour grapes": In my experience, the industry is indeed doggedly conservative--every language decision I have seen has been based on familiarity, programmer availability, risk-aversion, or political acceptability, never on technical merit per se. Not that these are unfounded considerations, but all work against new languages. And I could as easily lampoon your Panglossian dismissal of historical contingency. "Worse is Better" argues that C won because it was easier to implement, and ran well on small machines, not because it was better. Is this implausible to you?
Re ITA: I was not aware that they relied heavily on non-LISP code; I'll have to look that up.
lambda functions Posted Dec 14, 2005 2:39 UTC (Wed) by pimlott (guest, #1535) [Link] Funtional languages usually have special constructs or a library for manually managing memory, when required.I take that back somewhat: They have ways to explicitly allocate, deallocate, and modify references, but they don't have ways to use your own allocator, so far as I know.
lambda functions Posted Dec 9, 2005 9:09 UTC (Fri) by pkolloch (guest, #21709) [Link] Just to summarize what others have already made: I was not in awe with the prettiness of the construct. It is clearly much uglier than in probably any functional language. Yet, I was amazed that this is at all possible in a language like C++ (without language enhancements)!
lambda functions Posted Dec 15, 2005 18:55 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Greenspun's Tenth Law strikes again, eh?
|
|||||||||||||
![[Boost]](/images/ns/boost.png)