[Yui Unifex]

(it appears that nested quotes are broken :/)

My opinion is mostly based on MFC, since just about every piece of C++ code I've seen MS put out was built using it. I do recognize that this was due to a bad initial design that they simply never recovered from due to their own backwards compatibility, but it does well to serve as a warning to others.

Although I'm not fond of their bloated style of Hungarian either =).

[Kastagaar]

I got the whole backstory on MFC when I went and did a course in it.  Some horrible decisions went into that.  The recent ATL stuff isn't too bad, though.

And I don't like Hungarian, either.

Kas.

(edit: ATL, not AFX. And it's not that recent either, but what the heck).

[Kastagaar]

Oh yeah, to the OP: C++ is a multiparadigm language that is a near superset to C. The only reason I see to use C over C++ is the lack of a good compiler.

In summary, I would say to use C++, even if it's only as a "better C".

Kas.

[Tamsyn@zebedee.org]

[KaVir]

In my opinion:
Bananas are better than oranges are better than apples.
There's never a reason to eat apples except when you are forced.
Or unless you want to eat your fruit without peeling it

[Yui Unifex]

Java is an interesting language. It has some higher-level constructs that C++ lacks, but it's always tieing your hands behind your back in the name of safety. So it actually suffers from some of the same problems that C does which I talked about earlier, particularly that of operator overloading. It all reminds me of from a talk given by a Perl programmer. The makes for some pretty good reading, too =).

[Kastagaar]

Java's fun; it's simple and has many features. If its designers would lighten up a little bit wrt templates and operator overloading, it would be the best language in the world.

Your statement on C is a non-sequitur; it has nothing to do with Java. My original statement is based that comparing C to C++ is not an apples-to-oranges comparison, since with a good C++ compiler, you can compile (with minor modifications) C.

Kas.

[angelbob]

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

[Kastagaar]

(Reasons to use C over C++)

I can't say I've found a C++ compiler that, after having successfully compiled and linked, did not produce the expected output.  What I have found is that some C++ compilers do not implement portions of the langauge.  MSVC++ 6 does not support template-templates, for example.  There is a set of C++, however, that is implemented by all C++ compilers, though, and it is possible to stick to this.

I link to C++ libraries quite often, actually.  But in general, in either language, you only link against a library compiled by your own compiler.  In some cases, there are tools to help (Borland C++ has a tool to convert libraries between Borland and MS formats, for example).

Some of the more powerful C++ libraries are also header-based, which means that there's no separate library to link against, meaning that it "just works".

What, that you "can't debug operator=() because the only way to track an error is to throw an exception"?  Have you ever even looked up the rules of exception safety?  Come back when you can tell me what the "strong exception safety guarantee" is, and why it would apply to this operator.

Sure, MSVC++ is a pretty good compiler, despite its language support.  I suspect MSVC++.NET is pretty good too.  GNU C++ will, when compiling C-like code, will produce the same output as GNU C (tested as of version 3.2).  Except with better type checking, the ability to use *_cast<>, etc.  This is why you can use it as a "better C"...

The language is a better C.  But compiler support (sigh) is still lacking in some departments.  Such as compilers for proprietary platforms.  C, the compiler, is relatively easy to write.  C++ has many more features, and is a far more expressive and powerful language, and this is how it pays.

But, for what it's worth, many companies also use C++ in their embedded software.  It might be worth googling on "embedded C++" - a subset of the language considered by experts to be "safe" for embedded use.

That said, embedded software has its own set of rules, and is not a perfect counterexample.

So, in summary, I stand by my statement that there is no reason to use C over C++ except for the lack of a good compiler.

[enigma@zebedee]

[xanes]