本文是BYTE对若干开发者、公司技术负责人的调查报告，个人认为很值得一读。可惜我时间紧迫，无法为大家翻译，深表抱歉.
Whither Now C++?
By Steven J. Vaughan-Nichols
September 4, 2001
Oh the shame of it all! After years of being the language for real programming, C++ has lost its throne as being the most popular serious language to, God help us, Java.
The Evans Data Corporation predicts that sometime in 2002, about 55% of North American developers will spend at least some time working in Java.
That popularity is coming at the expense of C/C++ and Visual Basic. Throwing salt into the wound, by 2002, Evans Data predicts that only about 51% of programmers to still be working in C and C++ and their numbers will be declining fast.
What happened?
The Waning of C++
To find out, I went to the programmers and developers in the trenches. I spoke to dyed-in-the-wool C++ programmers who are now at least beginning to consider the alternatives. This is their story.
David W. Methvin, noted technology author and consultant, speaks for many when he says of C++, "If I never have to write another line of C/C++ code I would be a happy man. The meat of the C++ language has evolved into a monster, but worse yet the trimmings now outweigh the beef. Win32/MFC/ATL/COM all try to layer more abstractions onto the low-level language but they're a nightmare to learn and use, especially if you try to use them together and need to convert between disparate data representations. NuMega's BoundsChecker helps, but often even Microsoft sample code won't pass through it without complaint so you have to wonder when the creators can't get it right."
Not everyone would go so far as Methvin does though. Mark Bartosik, Principal Software Engineer at Michael Larkin Enterprises, agrees that, "There are many libraries for C++, and C++ can interface to many other languages notably C. This is both an advantage and a disadvantage. The language 'bindings' are not always ideal, this is where a lot of bugs creep in."
But, he believes C++'s real problem isn't the language or the libraries, it's the programmers. He explains, there are three classes of C++ programmer: C programmers; traditional programmers, whose understanding of the language comes from the Annotated Reference Manual (ARM) who don't use templates; and modern C++ programmers. Larkin says, "For the later category C++ offers extremely robust, expressive, powerful, efficient means to write high-quality reliable code. These programmers will be making the maximum use of templates, STL, and other template libraries. They are generally very knowledgeable. For the other two categories the outlook is not so rosy." His reasoning is that they simply don't have the deep understanding of C++ that's required to make the most of the language.
David Bradley, Software Engineer at Netscape/AOL, agrees that C++ is robust and powerful, but he thinks that "the complexity of the language" works against it. "I think there's a lot of baggage carried from C and as a language it's rather complex. I'm not sure they can be addressed without creating a new language. And I don't see Java as much of an improvement. I think we could do a lot better than that."
Other programmers don't think that C++'s complexity is worth addressing. Erik de Castro Lopo, CTO for the small consulting firm Mega Nerd Pty Ltd., says that C++ is "not my main language now and will not be in the future. I use it when I can do something in C++ which I can't do in C and is too slow in Python or Java." He's in Methvin's camp when he says that, "The language is a god-awful mess. It suffers badly from creeping featuritis. It cannot be fixed."
Serge Smeesters, a programmer/analyst for Belgium UCL-SESA, also not planning on using C++ in the future, puts it another way — he wants a language with more elegance. And, it must be said, whatever else C++ is, taken all in all, elegant isn't a word you'd use for it.
After all, as Mark Jordan, Software Engineer for Cambridge UK's Laboratory of Molecular Biology, explains, "I'm sick of battling with C++ to properly separate interface from implementation, and the template syntax is too unwieldy." While he "will continue to write libraries using C++...because everything can be interfaced to C code (extern 'C') and it's efficient. I am planning to shift my high level development to the Dylan language."
For others, it's simply a matter of programming efficiency. Alexey N. Solofnenko, Software Architect for CITech, says, "Java is replacing C++ in my projects. C++ is a good language" and it's suitable for application development but, for him, "Java just allows programmers to implement applications quicker. The resulting code is more portable." He's in good company. Peter N. Roth, President of Engineering Objects International, uses several languages, but he "was hoping C++ would be 'the last' language, alas..." he was wrong.
To some, though, beauty is in function, not mismatched libraries or an overabundance of features. Alan Floyd, Software Engineer at ADS Corporation, gushes that, "I LOVE C++, I like Java but I LOVE C++." Why? Because, "There is no doubt that C++ is not for every problem but it has so much flexibility that it can solve 95% of your needs. There are so many class libraries available and the standard library itself gives (you) a good abstraction to work with." To him the complaint that C++ has too much complexity misses the point. Floyd feels, "Its greatest strengths are its flexibility and feature-rich environment. Some people say this makes it too complex, but without complexity you will not have all the tools you need to do your job. Look at how much more complex Java is today as opposed to a few years ago. Complexity is necessary to solve problems."
Ivan Vecerina, Research Manger at XiTact, expands on the theme: "Really, C++ offers much more (than other languages), and really allows users to create high-level abstractions as libraries, and not be limited to those that are built into a specific language. C++ supports several development paradigms inexistent in other general-purpose languages, allows developers to work at higher levels of abstraction, and does so without sacrificing execution performance."
Other programmers aren't convinced that there are better alternatives to C++. Carl Daniels, Senior Software Engineer at Pixami Inc., states that, "Java has proven itself unsuitable for end-user custom application development, and I wouldn't even dream of using Java in any embedded application." After all, as Attila Feher, a C++ consultant wryly observes, "I took a close look at the MS Office suite. They look like (C++) applications to me."
Nevertheless, even in embedded systems, Java is, nevertheless, moving in. Evans's study found that almost a third of wireless PDA developers are using Java and J2ME. Would anyone have believed even two years ago that Java would be a player in these restricted memory, embedded devices? And, while Java isn't appearing in many end-user applications, it is finding a home in enterprise networking applications.
Even C++'s critics have to agree that when speed's the thing, C++ can still offer the best balance between low-level complexity (C and assembler), and higher level languages (Java and Python). But C++'s complexity seems to be catching up with it for all but its most devout fans.
C++ Woes
Vecerina, for example, believes that C++'s is proving too much for any new programmers to handle. He doesn't think it's the language's fault, though, "too many people (are) misusing and even misteaching it." He's not the only one who believes this.
Feher believes that, "C++ needs professional programmers and there are less and less of those animals. I see the most danger to C++ in today's 'education.' People teach C++ who do not even have a hint about what C++ is, that it has a standard, that C and C++ is not the same language!!!" In one extreme case, he tells of "one 'Java guy' who insisted for a year (that the programmers should) write our device-driver project in Java, because 'Java is better.' He did not care it would not work."
It's not just bad teachers. Carlos Moreno, Trainer and Software Developer with Mochima Software/AudioSystems, who knows a thing or two about teaching C++, thinks that a considerable fraction of C++ book authors are incompetent. "Most C++ books teach C with some C++ additions, followed by some object oriented and other features of C++." That's simply not the way it should be taught. "If books taught to use effectively the C++ standard library facilities instead of teaching C idioms, people could effectively write most applications without ever using pointers or dynamic memory allocation."
Daniels, though, thinks that C++'s very complexity is why it's proving hard to teach. He comments, C++ is "too complex for most people working in the programming field to fully grasp." But, "I see this as a deficiency in the average programmer more than a deficiency in C++."
However, it's more than just education. C++ has many internal and external problems. On the inside, Jordan is in good company when he says, "Template syntax is over the top. There has to be a way of simplifying it." Solofnenko, while thinking that templates are a good idea, believes that C++ needs "better template parameter definitions (for example, a type that a descendant of another type)."
And, Moreno also comments that a little too much C slipped into the C++ libraries, making it harder to practice good C++ coding. "The standard library has many inconsistencies, mainly when it comes to the subject of encouraging programmers to stick to C++ idioms and avoid C idioms."
Still, he goes on, "I think C++ is victim of all of the accusations that C deserves, only because many people pretend that they program in C++ when they really are programming in C. It's true that this is a double-edged argument: It could be argued that if the language allows you to do bad things, then the language is bad. This is a weak argument. Practically all languages allow you to write goto-based programs without a single function, subroutine, or class, and using exclusively global variables — would we then say that those programming languages are bad?"
Even Floyd, who loves the language, admits that, "Its greatest weaknesses is a flaw in the interface/implementation separation. A class exposes its private data/methods to the world and a programmer must use some tricks (that should be supported directly in the language) to overcome this."
Beyond the language proper though, other problems be-devil the language. Although C++ is an ANSI/ISO standard language, the compilers lag behind. Vecerina observes, "Compilers and standard libraries could still improve in terms of performance, compile time, IDE features, and tight standard compliance." He's one of many who agree on that score.
Hans Aberg, a visiting professor at the University of Stockholm, would also like to see "a good visual debugger. I use an IDE. Apart from syntactic coloring, the IDE also supports quick lookup of any name of used in the code; that is, one can quickly jump to the place where it is defined."
Most of the programmers I spoke to felt especially frustrated that the package with the best tools, Microsoft's Visual C++, is by far regarded as the most nonstandard C++ developer and compiler package. While, simultaneously, GCC is the most compliant with the standard but has the poorest IDE tools. Borland's C++ was usually ranked between the two.
And, most annoying of all, you simply can't take code from one development package to another and have even a hope of compiling it with another development tool's compiler. As it seems to always be the case in programming, code portability is more of an illusion than a reality.
In C++'s Favor
Martin Range, IT Consultant for OO Technologies, says it best, "Efficiency. Efficiency. Efficiency." When done well, C++ programs are hard to beat in both efficient use of system resources and speed.
It's also hard to argue with Feher, when he remarks, "I think one of the greatest strength of C++ is that you exactly know what is happening 'behind the scenes.' You are not at the mercy of a black box VM or a 'who knows in what state it is' garbage collector etc." It's an argument familiar to UNIX users, C++ may be more difficult to learn to use than its rivals, but it gives you unrivaled control.
C++ is, as Feher says, "the language, which can be used to build the 'infrastructure' of the IT industry." Indeed, it many ways it already has.
Bradley explains, "C++ is one of the few languages that I've used that really allows for near assembler level management of code but provides higher level features for managing larger, complex projects." I'm well versed in both C++ and Visual Basic. What I find is that VB works great for simple projects or prototypes. I've witnessed numerous projects struggle or fail because they went with Visual Basic. Initially everything was going great. The schedule was tight and things were on track or ahead of schedule. Then, the last 20% of the project needed to be completed. It was that last 20% that caused problems. Things that could be done in C++ fairly easy were very difficult to do in Visual Basic. I've found the same true of Java, although to a lesser degree."
Byte.com's own Martin Heller observes that, "C++ still survives for writing libraries, controls, system code, and code for handhelds and embedded systems. C++ now has the role that assembly language had 15 years ago and C had about 8 years ago — it's the language for die-hard bare-metal programming."
So it is that even as C++'s steep learning curve, nonstandard compliers, and over-reliance on its C ancestor works against it, and as newer languages gain more popularity, C++ will remain in a central, if no longer starring, role in development circles. C++ — there's still no substitute.
Steven J. Vaughan-Nichols (sjvn@yahoo.com) is a freelance writer who first wrote for Byte in 1989.
