C/C++ Users Journal August, 2005
I call them the Dialect Wars. If you're inclined (or obliged, in my case) to monitor the newsgroups on a regular basis, you see them being fought on a daily basis. The folks in comp.lang.c are probably the greatest purists. As far as the loudest contributors are concerned, C reached its zenith with the 1989 ANSI Standard (or the 1990 ISO version, if you're a citizen of the world). It picked up a bit of unimportant cruft in 1995 with Amendment 1, and went off the deep end with the 1999 revision; but if you ignore those later tinkerings, C is still the One True Language for getting things done. Heaven help you if you discuss any compiler-specific extensions, however conforming. And anyone who dares mention C++ is sent packing to comp.lang.c++.
Over in that newsgroup, C is pointedly ignored. It's basically Your Father's Programming Language. There's ongoing tension over the issue of conformance. One contingent laments the scarcity of compilers that completely conform to the 1998 C++ Standard. (They blame lazy implementors.) Another laments the presence of requirements that nobody wants and that are too hard to implement. (They blame an incompetent and unresponsive Standards committee.) But the real fight is with that upstart spinoff from C called Java. Specious performance comparisons have given way, in recent months, to endless arguments over the relative merits of automatic garbage collection versus smart pointers and well-thought-out storage management. Microsoft has stirred this pot with the incipient release of C++/CLI, truly a dialect with a foot in each camp; but even the knee-jerk Microsoft bashers have mostly adopted a wait-and-see attitude.
For the purest of the pure, there's comp.std.c. Here, you will find endless arguments based on the finest legalistic parsings of the C Standard, which is treated as a badly flawed divine revelation. Most of the "dialects" at issue are paper tigers—theoretical languages that represent different ideals of Truly Portable C. But the real entertainment comes from the persistent nihilists, who can reduce any sentence to meaningless rubble. Not for the faint of heart, or for anyone who needs to get code written for a living.
comp.std.c++ takes quite a different tack. Here you will find presented a steady stream of bright ideas, each of which should of course be added to the C++ Standard right away. Most these days take the form of template metaprogramming aids (a.k.a. Stupid Template Tricks). But you also get a succession of sermons on the One Right Way to add all sorts of difficult features, from multithreading to shared libraries to, yes, garbage collection. The C++ Standards committee gets off lighter than their C counterparts, I think because they are viewed more as temple scribes than as priests.
I also monitor a handful of microsoft.public.* newsgroups that deal with various aspects of C/C++ programming using Microsoft Visual C++. The excitement here stems from the presence of so many versions of VC++ still in active use, from the preStandard V6 to the Whidbey beta (a.k.a. V8), with several eVC packages off to the side for programming Windows/CE. The Microsoft bashing has gone way down in recent years, largely because VC++ is now much more conformant and visibly being enhanced on a regular basis. But with seven different dialects to choose from, there's plenty discussion about which ones are Good Enough (TM).
As a flaming pragmatist, I find the Dialect Wars mostly amusing. Our little shop produces code in a variety of dialects, depending on the need at hand:
• We write great quantities of code in Standard C. Besides the Standard C Library (obviously), that includes all our math libraries
and our basic support functions for C++ and Java. The only portability problems we encounter are occasional code-generator bugs in certain compilers. We never have to worry about whether this code will fail to compile.
• We also write great quantities of code in Standard C++. This includes nearly all of the Standard C++ Library and the first library Technical Report (a.k.a. TR1), plus smaller bits mandated by other TRs. It takes rather more preprocessor logic, to dance around various compiler limitations, but it lets us keep a common code base for all the platforms we support.
• We write quite a bit in C++/CLI, so far just for Microsoft. It's still a learning experience.
• We write small quantities of code in compiler-dependent C, mostly to deal with all those VC++ and eVC dialects from Microsoft. It's not always fun, but the market is simply too big to ignore.
Which is our favorite dialect? The one that gets the particular job done most effectively. But try saying that on a newsgroup.
P.J. Plauger
Senior Contributing Editor
pjp@plauger.com