Oh boy. I was recently asked the 64-bit question: "will CUJ change its name to C/C++/C# Users Journal?" The answer is a big fat No. Same thing goes for Java. Covering C and C++ is challenging enough, thank you. It will get even more challenging if these two languages start to diverge, or if C and C++ programmers go their separate ways.
I know some C++ enthusiasts are eager to cut all tether lines to C. They bemoan the awful things backward compatibility has done to C++. The way I see it, backward compatibility has made C++ messy, somewhat inconsistent, and ... ubiquitous. I wonder if the same people who hate the C in C++ would hate to see thousands of new programmers embracing their favorite language. I don't think so. These potential new users are embedded systems developers, who are still immersed in C, but are very much interested in C++. Every time I go to one of Dan Saks' C++ courses at the ESC (Embedded Systems Conference), I practically have to drag him out of there afterward. He is bombarded with questions; his sessions are absolutely packed. For these developers, the best path is to build on their knowledge of C, and to adopt C++ features as they understand them and have considered their costs. It would be a shame if embedded developers were told that their C expertise was of no value, or even, as some have suggested, a liability!
When I went to the ESC this fall, I was struck once again by the diversity of our audience. There are programmers writing code for DSPs (Digital Signal Processors) who are just now grudgingly switching from assembly language to C. On the other end of the abstraction scale, there are C++ programmers doing really weird and wonderful stuff with templates, things you might not even think are possible. As you can imagine, I didn't meet any of the latter walking the floors of ESC. Maybe they should consider attending, though. They may have something to offer embedded systems developers.
Let's look at the most esoteric branch of C++ development — template metaprogramming — and consider some of its underlying goals. Those goals include:
- run-time efficiency — do as much of the work at compile time as possible
- compactness of code — select the optimum types automatically, again at compile time
- safety — catch errors at compile time, not at run time
Gee, those same goals are shared by embedded developers! Is there a potential for unification here? Possibly. It would require quite a lot of stretching on both sides. Template gurus would have to keep things simple, because C++ compilers for embedded systems are bound to have limited template facilities. (Note: I am not referring here to "Embedded C++," which doesn't even have templates. Embedded C++ is a subset of of C++ being promoted by some vendors as a standard for embedded systems. It remains to be seen how it will fare.) Embedded programmers would have to keep an open mind about C++, and template programming in particular. (For a taste of template metaprogramming, see Andrei Alexadrescu's article, "Generic<Programming>: Mappings Between Types and Values" on our website at http://www.cuj.com/experts/1810/toc.html.) For my part, I would pay top dollar for an article that showed a practical application of template metaprogramming for embedded systems. I am not kidding. In the meantime, I will publish articles from both ends of the spectrum, and pray I don't scare anyone off.
I have obvious reasons for wanting C and C++ developers to keep working together. But beyond my self-serving motives, I think it would be good for both languages, as it has undeniably been in the past. I trust I am not the only one left who still thinks so.
Marc Briand
Editor-in-Chief