Even though three of us (me, Kevin and Dale) blog now at OCI North, and two more read them, we still practice the ancient ritual of printing out interesting articles on paper (and thanks to Kristin we have a Samsung CLP-510N color laser now) and secretly place them on the little round table where we sit around to have our occasional eXtreme stand-up meetings (gazing into the crystal ball, as Rob puts it.)
Last week, my contribution is one of Ted Newards's blogs, in which he marveled at the state of the C++ programming language:
Ted Neward: What I ran across, of course, was the Boost libraries,
which provide a whole slew of free/open-source C++ template libraries,
ranging from "function" ("Function object wrappers for deferred calls
or callbacks") to "mpl" ("Template metaprogramming framework of
compile-time algorithms, sequences and metafunction classes"), to
"pool" ("Memory pool management"), to "preprocessor" ("Preprocessor
metaprogramming tools including repetition and recursion"). They've
even got "lambda", which describes itself as "Define small unnamed
function objects at the actual call site, and more". Sounds kinda like
closures....
...
Gotta admit, maybe it's time to go back and explore my programming
roots; some of this stuff sounds pretty interesting and, better yet,
pretty powerful. Maybe I was too quick to jump to the managed world...
Ten months after coming back to a C++ project from six years of Java, I have to say Ted's remark is very observant and matches my experience very accurately. I was expecting something far worse ten months ago: pointers passed around, memory leaks everywhere, home-grown frameworks for everything, overloaded operators making "a = b;" mean something completely different, objects being cast to unrelated types, etc. None materialized.
I think there are several reasons for this. Major among them is the Boost libraries. The boost::shared_ptr class template brought sanity to memory management. We are also using boost::lexical_cast for value conversions, and boost::bind for functional style programming using the Standard Template Library.
Another reason has to do with people. The native C++ programmers on the project are very knowledgeable about the language, the tools, and the design philosophy of C++. Kevin, for example, keeps a copy of the C++ Standard open all the time and can answer any C++ language questions in an instant. C++ hasn't been a language that people flocked to for the past ten years. People who are here secretly loves the complexity and their mind were kept very sharp because of it, which is a good thing.
Yet one more reason for the seeming effortlessness of the project is the use of modern C++ features and design techniques. The fact that the project is a "new" project and the architect and designers have freer hands made this different from other "legacy" C++ projects where developers have to use older techniques to make older compilers and libraries happy.
Just like there are people who left C++ for Java and kept a mental image of the circa 1996 C++ with them, there are people who tried and rejected Java for something else yet kept a mental image of the circa 1999 Java with them. (Therefore all the "Java is only good at Applets", "Swing is too slow", talks.)
Now that I have some experience of going back to an older language, I'd advise others to not cling on the the old image of the languages you left and make an effort to find the improvements made since you left. You'd be surprised.
I think I can also tie this up with two of the advices from the Pragmatic Programmers. One of the advice is to keep your mind sharp (full brainer.) And challenging yourself is always a good thing. Another of the advice is to learn new languages. Of course nowadays they recommend Ruby as the language to learn. But you can learn a whole lot about design and programming paradigms by learning C++ anew.
Previous Topic
