What case is that? If it's the one where I stated that C++ is cleaner than C for some purposes (and to which you agreed), then that's already been proven. I am simply discussing what considerations the language designers were bound to over and above the features you describe. But you're missing an important point (and oddly enough, one that you quoted):
I don't think the language designers were all sitting around a table thinking about designing a totally new language when suddenly one of them had the brilliant idea to base it off C. No, it evolved from C; rather than itself being a separate entity. So no, I don't "justify this way", I'm simply telling you how things probably were back then. Now you should understand that C++ isn't the way it is just because it wanted to be popular, but because it wanted to supplement C.

That's fine. Just be aware that 'actual merits' for some people include backwards compatibility with their previous codebases and ways of doing things.

You mean syntactic ugliness like:
[code] /* C version */
char *build_magic_string (...) {
static char magic[256];
...
return magic;
}[/quote]
As opposed to:
[code] // C++ version
string build_magic_string (...) {
string magic;
...
return magic;
}[/quote]
And all that reduced range of debugging tools, like the exact same debugger and tools they were using before? Yeah. You got me there.

The lack of forced object-oriented design is an incredible plus when you simply want to take advantage of one or two features but also want your codebase to use the same idioms and design as before. Many C++ codebases use procedural C code, and this is a very good thing for programmers, because they have to do a minimal amount of porting. If you're suggesting that to take advantage of a few useful features, a programmer should have to refactor and redesign his codebase, you're crazier than I thought you were.

I'd been arguing (for pretty much this whole thread) that C++ tends to encourage bad code. We then hit the point last page where I suggested a metric for programming languages based on whether their feature set encouraged clean code. It sounds like you're apologizing for C++ scoring badly on that metric by saying it gains C backwards-compatibility in return. Is that what you're doing?

Well, yes. It started off as a preprocessor. I still choose to judge it on its merits as a language. You're welcome to judge it on its history as a language instead, but I'll laugh at you.

I'm aware of that. And you misspelled "supplant" ;-)

Actually, no. I was thinking of template syntax and class declaration syntax. The couple of things you can do with C++ without classes or templates or operator overloading are kinda cool. I wouldn't take the extra space hit in return for default arguments to functions, and they're not done that well anyway, but they're not bad. Not excellent, but they *are* one of the early things that worked in a preprocessor. So I provide them historical slack, if not slack on actual execution (satisfied?)

Well, other than purify working right. And many profilers. And a bunch of memory debugging tools. But if "the exact same debugger and tools they were using before" is VC++, you're right. So yeah, if you only use your compiler and one debugger, you're probably golden. In that case, there's no such thing as a "reduced range of debugging tools" except "no debugging tools", though, so I can see why you take exception.

You seem to read a lot of my mental state into my random utterances, so would probably be hard for me to be crazier than you thought I was and still successfully use a keyboard.

The problem with giving the programmer "a few useful features" and letting him run with it is that he'll either hate them, in which case nothing will happen, or he'll like them and use them everywhere. It's that second scenario, the one where you bastardize the codebase by adding a second paradigm on top of the first one, that gets folks into trouble.

Do I think that people should redesign their whole codebase to add a few useful features? No. But I find that adding a few useful *language* features after the fact is usually a major inviation to trouble. I've seen it work, mostly, by adding callout to another language. Usually that means that most developers on the project only know one language or the other. There are at least well-documented interfaces between the two, but debugging anything cross-language remains a pain.

You can add features after the fact with an extra preprocessor, too, the way C++ used to work. SGI apparently does their arcane template-like data structure stuff that way. By and large, though, nobody does. Why do you think that is? My vote would be: adding features to the language, especially when you have a large existing codebase, is usually an invitation to trouble.

By contrast, switching languages entirely guarantees that you do *not* have a large existing codebase, one way or the other. Am I in favor of switching languages instead? Not usually. Usually I'm in favor of keeping your large existing codebase in the language in which it was written, or rewriting it pretty much entirely.

Allow me to clarify your confusion with a quote:
I am simply providing a reason why languages often must consider more than your metric. I even said that it was a good metric, I simply had issues about its completeness. I'm not apologizing for anything out here, and I'll be the first one to say that certain things have been done far better in other languages. I simply wish to widen the view that you provided.

You're being silly. I offer some history and a major feature related to that history, and you say I'm judging entirely by the history. This feature is even part of the "important point" I had to quote due to your missing it the first time! Now you've missed it again *and* leapt to a false conclusion. For shame. To make it completely black and white to you: This history shows why C++ is backwards compatible with C. I judge by *features* not history, and this is a ridiculously important feature.

I meant what I said.

If you're talking about Rational Purify, it does indeed support C++. If you're talking about Pure Software's Purify, it also supports C++. If the exact same debugger and tools is gdb, gprof, and valgrind, which is what the vast majority of the mud community uses, then I'm also right. Most memory debugging tools I've used simply preload and hook into malloc/free, so they don't care what language is being used. Of course all of the C-compliant code that you write is still debuggable by the C-only tools (like lint), but there is a C++ equivalent for almost any operation.

It's a good thing we have you to clarify the psychology of the programmer. Don't you think that it's best to let the programmer decide what he wants to do, rather than deciding it for him? I can think of dozens of scenarios where moving a C codebase to C++ don't include your two extrapolations: It could be for library support (yes, there are C++-only libraries), educational purposes, or to sync the codebase with with a planned migration to a different paradigm in which individual modules are added onto or replaced.

I think the people over at Trolltech would disagree with you, and they're adding features onto an already large featureset. For those that aren't aware of the best gui toolkit around, Qt uses a meta-object compiler to add signal/slot functionality to C++.

How hard are you willing to work to turn the tone of this into a flame war? We've already got all the usual attributes of one, but we've managed to stay reasonably civil and on-topic.

But yes, you did in fact offer a major feature. I still choose not to weight the history itself in my consideration of the language. I weight the feature in my consideration of the language, and I in fact debate precisely that feature later in the same message. I'm not ignoring that feature, no matter how many time you repeat that I am. Happy?

They're actually different revisions of the same software. Pure Software merged to become Pure/Atria, which was bought by Rational. So yes, I'm talking about both. Have you actually used the C++ support you mention, say with VC++, on an actual project? They have several *really* annoying bugs that make sorting through the warnings in C++ take several times as long. That whole mismatched new/free warning is the main culprit, though there are several other things that make it hard enough to track down that I'm 90% sure they don't use C++ much internally.
I haven't used the new Rational revision with gcc/g++ on a Unix system, only the older Pure Software version. It also has serious bugs that make it hard to use, but the new (far more expensive) version might fix that.

Interesting. I'm not familiar with valgrind, I'll look it up. Yes, I was referring to gprof, as well as tools like ElectricFence.

And if you don't care what function is being called, or whether the tool can deal with extra layers of function calls and name-mangling, you're golden. Of course, if the tool *doesn't* deal gracefully (in a way specific to your C++ compiler) with name-mangling...

So basically, you're not in favor of language designers doing *anything* besides tacking on features until the whole edifice collapses? Are you a big Ada fan, then? It was something like ten years after their language standardization before they had a compiler that supported them all. C++ only managed the more modest feat of taking ten years to hash out the details, at least those that were ever agreed on.

I believe that by and large, simple clean languages are a very good idea. I believe that languages like C++ and Perl (which I would put near the far opposite end of the current spectrum from "simple, clean languages") have very specific uses, but primarily those uses boil down to "prototyping". I believe that a hybrid prototyping/systems language (like C++) encourages people to build on those prototypes to turn them into the finished product, which creates lousy finished products (see "The Mythical Man-Month" for more on this phenomenon -- I know you've read it, you recommend it on your site).

I'm well aware of them. We were busily locking the programmers into specific C++ compilers by including some of them in the Operating System when I left Palm. While related, that's not actually the reason I left Palm.

This comes closest to a good reason for a mixed-paradigm language (between Procedural/Systems and OO, anyway) of any I've heard.
I've never seen this done well, though I've seen it done badly many times. I'm referring specifically to C-to-C++ transitions when I say that.

Here, let me ask you a question as a thought exercise, and because I need to know how crazy *I* should consider *you*. Say there was a tool which advertised a particular service, but didn't usefully perform. Using that tool was always worse than not using that tool for the advertised purposes. There were conceivable uses for the tool, but the common and advertised ones weren't really among them.
Should the tool exist?

I'm a GTK+ man, myself. They do a full dynamic inheritance system for widgets in C rather than preprocessing C++ to get the same result. I'd expect (sight unseen) that the Qt way requires storing less of the type system at runtime, but allows for less adding dynamic stuff at runtime. S'okay, I like dynamic type systems better than I like decreased memory footprint when it comes to GUI toolkits on the desktop. Where memory footprint matters (at Palm, for instance) we used neither so it was a non-issue.

If Qt is preprocessing C++ to add features then I'll remember to avoid it. "Meta-object compiler" is certainly a lovely euphemism for that, though.

My issue is not necessarily with you ignoring the feature, but with you believing that I'm judging based on the history rather than the feature here:
I used it for a little while on a project, but I ended up moving the development to a Linux machine with valgrind. I honestly didn't give Rational Purify as much use as I've given valgrind, though, so I wasn't aware of any of the bugs it had with C++.

gprof has a switch that can be toggled for C++ name mangling. Interestingly enough, I just checked the manpage on FreeBSD 4.5 and 5.0, and couldn't find the switch in the manual. I'm positive it's in the Linux manpage, though. I haven't used ElectricFence.

I don't think that this conclusion follows from my statement. I'm in favor of language designers adding features that make a language more useful than it is, and properly weighing the constructs involved in any given feature to make them consistent, clean, and unobtrusive. Some constructs (like Ruby's incredible object orientation and concept of iterators) do away with things like the 'for' loop, but since there is a satisfactory alternative, I don't think that the designers should concentrate on adding a for loop. From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming. So while I agree that there are very few features that I would *not* want to have in a language, designers often have other overriding concerns and adding 'ugly' features simply becomes a matter of priority, as they fall to the bottom of things to be done. To be idealistic, if I could have a language that did anything I could ever want and much more, so long as the 'much more' part did not impact the performance of the 'anything I could ever want' part, I'd use it. For now, I simply have to pick and choose various languages based on how well their particular philosophies fit what I want to build, which makes crossovers (such as a rapidly-developed but performance-critical application) much more difficult to write (because of interface concerns) than I believe it should be.

I'm not sure if I'm a fan of it... I've never used it =).

This is an interesting question, but I don't think I'm in a position to answer a yes or no here. Oftentimes the common and advertised uses for something fall by the wayside as people think up innovative uses for things, so it's difficult to tell where something really fits in with one's goals. If someone else has an interest in the tool, who am I to tell him that the tool should not exist? If noone has an interest in the tool, why is it worth my time to even consider its existance? If many people hate the tool, and I have no interest in it, I probably wouldn't stop them from causing it to cease to exist, but I would take no action myself. If I have an interest in one of the tool's uses, then I would probably think that it should exist. This is presumably because I have evaluated my options in relation to the particular use and the tool, and have decided that using the tool over some other tool was in my best interests.

The signals and slots are dynamic, and type-safe.

<i>"From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming."</i>

Yup. Though it's amusing how many people manage to randomly do it on-line without nearly as much time or effort.

The big difference between them and what standards bodies are trying to do is that most people spell out what their implementation does, but not what the language guarantees. You're probably familiar with the same distinction from designing libraries -- "if you do this, the behavior is undefined", even though your library may always do the same thing in response to that. You just don't want to guarantee it forever, or in all circumstances.

Plus, of course, the standards bodies are dealing with established languages and so they have to deal with implementation issues a lot more carefully than most, and they usually need to do so without taking the time to actually implement the changes they mention. A difficult job, that. Particularly in C++ where different compilers still do genuinely different things to implement certain features, so it can be hard to tell if you're breaking something that somebody's doing.

A decent C++ ABI (Application Binary Interface) would solve a lot of that problem, but that's been "just about to happen" for ten years and counting so I'm not holding my breath.

Hey there,

I've been watching this thread for a while now, and I've actually recommended it to a few programmers I know who like to rant on and on about this very topic. Having very little programming experience total to draw from, and none in the area of C++, I've had to take what I could from the thread, mainly looking at the philosophies of each person and deciding which made more sense to me.

In the end, I have no opinion on which is a "better" language. However: Yui, go work for M$. Their PR department would worship you.

-Visko

For the Evil Empire?!

I think that MS' style of C++ is one of the best, most prominent examples of how you can go wrong with the language =).

10 PRINT "I code my MUD in BASIC!"
20 GOTO 10

Are you talking about Hungarian, The Code That Is MFC, all of the above or something else?

Kas.

(Edit: Ack! that came out bad first time around)

(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 =).

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).

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.

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

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 =).

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.

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

(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.