Reusable code saves time and effort in testing and documentation. The C++ algorithms, containers, function objects, and predicates work together to provide the developer with the tools necessary to create such generic programming. In this article, Tracey and Cameron Hughes show some of the specific uses for predicates and function objects in C++.
Predicates and Function Objects in C++
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I was hoping for some useful, clever idioms but all the article does is explain was a function object is (and anyone who has more than a basic knowlege of C++ should already know) and provide some “foo + bar” examples that I do not find in the least bit useful.
I’m not trying to sound flamey, but this is not an article, this is an exerpt of “C++ for Dummies” type stuff. Disappointing.
This article describes building a part of an ad-hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.
This is YA example of the “modern” approach to C++, which focuses on stylishness and elegance rather than practicality. It sells a lot of books and it’s hard to outsource or deny tenure to Gurus, but it really doesn’t help the guys in the trenches much. Like I tell my VP when he starts in on ActiveX controls again: almost never has that approach actually saved us time or money in the long run.
What I got from Modern C++ Design was a load of techniques that took more time and effort than “reinventing the wheel.” What’s the point of saving 50 lines of (simple, if tedious) code if it takes an extra day to figure out how and 200 more lines of comments in case it ever has to be maintained? If an expression template library like boost or loki chokes your compiler or doesn’t do exactly what you need now (and in the future), it’s often faster and easier to rewrite it from scratch. As a bonus, an “old fashioned” rewrite will be more portable and debuggable and can be maintained by other than a top 1% engineer.
The C++ Standards Committee and all the self proclaimed luminaries seem to want to turn C++ into a language with the power/productivity of Haskell or lisp. Unfortunately, C++ isn’t (and was never intended to be) such a thing, and no amount of bolted on kludgery is going to do more than make it bigger, slower, and harder to learn. If you want, e.g., useful first class/higher order functions (which in turn require garbage collection, etc.), use a language designed for that. If you have the talent, can afford a longer development cycle, and want high performance GUI programs and low level procedural access to (most) OS’s, C++ is a good choice.
What I got from Modern C++ Design was a load of techniques that took more time and effort than “reinventing the wheel.”
Modern C++ Design is probably not really meant for grunts. What it does offer is a way to write powerful, extendable and reusable components. This information is of most use to library developers.
If an expression template library like boost or loki chokes your compiler or doesn’t do exactly what you need now (and in the future), it’s often faster and easier to rewrite it from scratch.
Only a few of the boost libs are based on expression templates. Perhaps you just meant template? Anyway, if the stuff you can write from scratch rival the quality of the boost libraries and you do it in reasonable time then I strongly suggest you start contributing to boost. You would probably be a real asset.
The C++ Standards Committee and all the self proclaimed luminaries seem to want to turn C++ into a language with the power/productivity of Haskell or lisp.
Fortunately, the Committee is focused both on making C++ a better language and maintaining backwards compatibility. This is good for all those who are interested in writing modern C++ code and it is equally good for all those who maintain that C++ is “C with classes”.
“If you want, e.g., useful first class/higher order functions (which in turn require garbage collection, etc.), use a language designed for that.”
As long as C++ keeps the “you only pay for what you use” principle, I see no reason why C++ shouldn’t get more productive features. Garbage collector (which will be optional) for example sounds like a great thing to have as a part of standard C++.
As long as C++ keeps the “you only pay for what you use” principle, I see no reason why C++ shouldn’t get more productive features
Unfortunately, that isn’t the way it works. Compiler makers have to support new standards or get beaten up for “noncompliance” (guess who writes compiler reviews.) Adding garbage collection to C++, for example, (which I have no need or desire for anyway, I saw all I needed before fleeing C# in disgust) will cost me: I have to pay for the time that gets sucked away from making useful stuff better.
If it was only a matter of enthusiasts creating their dream libraries, I wouldn’t care: I’d read /. or OSNews headlines and the occasional article that looked interesting. All too many of these guys, however, have enough pull on the Standards Committee (if not a bloody seat) to force their visions on everyone else.
It’s not that I hate C++, or that I refuse to use it, I just find it unecessarily confusing and inelegant. I like simple yet powerful paradigms in programming languages, yet C++ has various complex ideas that are more intimidating than powerful.
For every programmer who finds C++’s advanced features to save time or LOC, ten more are using them to write crappier code and otherwise shoot themselves in the foot.
C++ shares with Algol-68 the property of having a predecessory language that was an improvement.
“Modern” C++ design is merely a baroque attempt to make the language do things it was never designed for and isn’t particularly good at.
If you must use C++, it is best to stick with Koenig-style “C++ as a safer C” development styles.
If you want the properties that “Modern” C++ design is attempting to impose on the language, it would be far better to use languages which already have those properties.
Nuff said.