|
Wow. I haven't looked back here in, like, forever.
My favorite reasons to use C instead of C++ are:
compatibility: any two C compilers will produce *much* more similar output (in terms of what bugs occur, for instance) than two C++ compilers. You avoid the standard Java "write once, debug everywhere" problem :-)
linking: you can link almost anything to a C library, and almost nothing to a C++ library. Name-mangling sucks. Yes, I'm aware you can use a lot of 'extern "C"' statements to get roughly this behavior, but that requires an extra layer of adapting your interface in most cases, which is slow, inconvenient and ugly. "C plus a layer of slow, inconvenient and ugly" is not "a better C".
Debuggers and tools. Remember that discussion between Yui and me earlier about debuggers and tools? I still agree with all those things I said earlier. Remember those examples? They're still examples.
The lack of a good compiler. You mention this one. "C++ isn't any slower than C with a good compiler, C++ isn't any larger than C with a good compiler, C++ compiles as fast as C with a good compiler", yadda yadda yadda. Show me a good compiler, anywhere, on any platform, and maybe we'll talk. Incidentally, most C++ compilers *do* catch more bugs than most C compilers, even today. GCC, at least with "-Wall" (which I always use, in both languages) is a notable exception. You can fix this by using a Lint program, though.
I'd refer to C++ as "a larger, more complex C". Calling it a "better C" is something I still find amusing. Who still uses C in this day and age? Well, Palm, Broadcom and NVidia, to name my last three employers.
Operating Systems companies don't like extra data being added in random places, and they need compatibility and linking. Hardware companies? Ditto, plus they need code that is fast, small and controllable. And people who really need things to work can't afford compiler bugs, and prefer older, better-tested languages. Alas, that's why some of them even use things like ForTran and Pascal -- for what they're doing, that's still the best available.
Embedded software companies (Palm, Broadcom, VxWorks...) need stuff to be small, but also need to know where data gets allocated...
All of these folks still, by and large, use C. It's not because of inertia. It's because C++ still honestly doesn't work as well for them.
Is C++ a "better C"? Not for any of the kinds of companies I mention. That's why they don't use it, at least not for their core stuff. Palm used some C++ for non-handheld non-OS stuff, for instance, like their desktop software. Broadcom is being enough that I'm *sure* somebody there uses it, I only worked on their embedded set-top video and graphics stuff.
On the other hand, is C++ a "larger C"? Yes, and not just in terms of feature set. That's why you don't see many C++ apps on the Palm :-) Palm apps are tiny, and C++ bloats that by a vast amount in very short order. I'm sure you can give me all the reasons that doesn't have to happen, in theory. In practice, that's what happens.
Random aside: I'm definitely not Java's biggest fan, since it's a single-inheritance single-dispatch attempt at an OO language, and the bytecode is just *horrible*. That's why the repeated Sun attempts at a Java processor (one that runs Java bytecode directly in the hardware) have flopped so miserably. But I *do* thing that Java, language-design-wise, is a half-step up from C++. Or a half-step down from C.
When Ghandi was asked what he thought of Western Civilization, he responded, "I think it would be a good idea." If you ask me about what I think of Object Oriented-ness in C++, I'd say, "I think it would be a good idea." :-P
|