Cee Plus Plus

"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?"

-- Tom Cargil, _C++_Journal_

See also this 1998 Interview with Stroustrup. (Not sure of its authenticity, but funny! - in a Ha Ha Only Serious fashion) harmful.cat-v.org

See also Extra Legs Ontoa Dog for other languages. (And if you think a destructor can not be pure virtual, see www.gotw.ca )

Cee Plus Plus is a monstrously overgrown macro package that simulates some aspects of Object Oriented programming in a conventional, strongly typed, C environment.

An interesting claim, given how little macros are used in C++, and how C++ answers all definition required for support of Object Oriented programming. Instead, we could say: "C++ is a language which supports paradigms including OO in a strongly typed, simple environment."

{Both of you are wrong. Cee Plus Plus isn't strongly typed... not with casting and covariant parameters to subclass methods.}

It's true if you consider the programming language constructs of the language to be structural macros. This is in fact what they are; for example the C++ utterance

class foo :
public bar { ... };

is essentially a macro invocation, denoted by the class keyword. The remaining pieces of the syntax are basically arguments for the macro call. The braces, colon and all that are just syntactic sugar that establishes the pattern match. In the compiler, once the pattern is matched, the relevant pieces are extracted and some translation is emitted. If the C language supported sufficiently powerful structural macros, the features of C++ could have been provided just as a library of structural macros, rather than as a whole new language definition requiring a new compiler.

This is true of all languages, more or less. Programming Languages Are Syntactic Sugar and all that.

(And in the early days of C++, when one used cfront to translate C++ to C; it was more so. Most modern C++ compilers do not translate to C as an intermediate step, however; they compile C++ to machine code directly (although it is rather ironic that the most standards-compliant compiler available, Comeau Cee Plus Plus, is implemented by translating C++ to C...)).

At any rate, so what?

Note that while a C++ to C compiler / translator / preprocessor can change C++ to C code which compiles down roughly equivalently in most cases, C++ exceptions cannot be translated to standard C and be as efficient as C++ exceptions on a good C++ compiler. One cannot (easily) automate translating C++ exceptions to equivalently efficient standard C, aka with the table approach. However, the rest of C++ 03 is simple syntantic sugar translatable 1 to 1 to C.

I'd argue that the template feature in C++ is nothing more than a macro package with a lot of sugar on top. It's also a macro package that invites implementing huge recursive macro expansions, and that is where the monstrosity comes in.

I am curious about your use of 'nothing more than'. If you mean 'macro' in the rather limited sense of C's pre-processor(why they called them macros I will never understand...), then I think you are quite wrong; C++ templates are a step towards something worthwhile. Only a very small step. It is the implementation that makes them a monstrosity. On the other hand, if you meant a real macro system like, say lisp's, then I can't understand 'mere' in this context. But I will agree that C++ templates are a pale shadow of that sort of power.

Yes, that is in fact what I mean. You actually agree with me. With the template implementation as it looks like today, they have re-implemented a macro-language on top of C (well, C with classes then). If I want a smart macro language, I'll use Lisp. And no, I don't believe that having macros in a statically compiled language is a good thing.

A medium-sized Language Pissing Match has been moved from this space to Java Vs Cpp.

I saw a C++ book by Alan J. Holub called "Enough Rope To Shoot Yourself In The Foot" [ISBN: 0070296898]. Didn't read it, so I can't vouch for the contents, but the title really sums the situation up!

See the Amazon link for some really mixed opinions on this book.

Okay, speaking as both detractor and defender of C++, I've had just about enough of me. I blow the crap out of this language and then get all hoity toity when someone else does it too. The nerve of me. What a bum.

Still I say, despite the objections I raise, that there's a time and a place for Cee Plus Plus. Let's try talking about that before we get any more schizoid than we are already: When Should We Use Cee Plus Plus? When Should We Use Java? -- Peter Merel

In my own work, I've found that C++ is far superior to C for low-level bit-frobbing (like Twain plugins and image processing code). I use it whenever Java is inappropriate [non-application code plugins, etc.]. At the simplest level, C++ is a superset of C for all practical purposes, so anything that can (or MUST) be done in C can be done in C++ with the additional benefits of templates, in-line functions, classes with or without virtual functions, and so on. -- Keith Ray

In my own work, I've found that plain old C is far superior to C++ for low-level bit-frobbing...

This thread probably doesn't belong here but... I have found just the opposite to be true. For low-level work, I really need the more stringent type-system of C++. C is just too loose and does not allow you to program with Const Correctness. Also, passing C function pointers is much slower [and more error-prone] than using generic-style function objects and parameterization. The only bodge is that many low-level API's (such as devices) are written in C, so it is difficult when the API you are using prototypes functions to take a "char*" when you know that the pointer is not modified and should be a "const char*" or "char* const". Other than this, I find C++ to be far superior to C for low-level work. Of course, if you are the "kid in the cookie jar" type, you may be better off with C, which is less strongly typed than C++ and let you get away with more. -- Robert Di Falco

Is there a decent internet account of what coding methods should and should not be used as far as C++ (or C) is concerned?

See Enough Rope To Shoot Yourself In The Foot book. It ain't half bad.

Personally, I think that a better guideline is "use only what you need." I find that strict coding standards of "use this" and "don't use this" hide an embedded assumption that all programs you write will be like some simple subset that the writers had in mind. I say that when using member function pointers through templated generic functions simplifies your program, then do it.

(Otherwise keep your hands off that icky complicated stuff! ;-)

-- Jeff Grigg

I am not sure I understand the initial statement in this section. I have not seen any operation I could do in C that I could not do in C++. The only difference in C++ is the packaging of the methods into classes. The few things I have not been able to do in C++ usually required me to revert to Assembly Language, not C. -- Wayne Mack

"The only difference in [between C and (?)] C++ is the packaging of the methods into classes". Seriously? That's the only difference you can see between C and C++? Exceptions, templates, operators, function over-loading yadda yadda Nick Keighley

One of the things I like about C++ is the ability it gives you to specify the types of what you are working with. This enables the compiler to catch errors at compile-time that would wait until run-time in some other languages. (And in some languages, you have to write the run-time checks yourself.) For example, suppose I had a type for a homogeneous set of objects and I wanted to write a function to find the union of two such sets. In C++ I can write

template <class T> set<T> set_union(set<T> const & x, set<T> const & y) { ... };

In Java I can create a Set class, but either it has to be a set of Objects or I have to tell the set what it is a set of when it is constructed. Then my definition becomes:

public static Set setUnion(Set x, Set y) { ... };

This doesn't specify that the sets have to be sets of the same type of object.

In Scheme I can't even go that far:

(define set-union (lambda (x y) ... ))

I can't say in Scheme that x and y have to be sets. And in Forth?

SET-UNION ... ;

I can't even specify the number of parameters in the language. I have to use a comment.

I think that the more you have to rely on comments to express something about a function in a language, the lower the level of the language. Comments are not checked by the compiler and they can be misleading or incorrect. But in C++ the compiler checks everything... and that prevents bugs. -- Edward Kiser

I agree that I'd rather express something in code than in a comment. These "somethings" you are expressing about the function - perhaps they don't really need to be expressed at all? Helping The Compiler

One of the things I like about C++ is the ability it gives you to specify the types of what you are working with.

Perhaps, in that case, you should be using Objective Caml, or some other language with Hindley Milner Type Inference?

That's a good idea. I learnt C++ after OCaml, when someone shown me that C++ provides the same level of expressivity. I still like OCaml. It's just that C++ is available out of the box nearly everywhere. So I don't get those weird looks any more.

Bjarne Stroustrup had something to say in an interview about times and the differing acceptance of things:

Q: If you were to start from scratch today and design C++ over again, what would you do differently?

A: Of course, you can never do a language over again. That would be pointless, and every language is a child of its time. If I were to design a language today, I would again have to make trade-offs between logical beauty, efficiency, generality, implementation complexity, and people's tastes. It is important to remember how much people's tastes are conditioned by what they are used to.

Logical beauty? Taste? These are apparent in C++????

.....He was talking about how he would do a language today. He was not describing C++ as we know it, or of modifying it.

Er, read again. He said "I would again have to ..." Clearly he felt that he had already made such trade-offs in C++ as it stands. Equally clearly, to me at least, he chose efficiency and implementation complexity over logical beauty and taste every time.

Read even again... He said he would 'again have to MAKE TRADE-OFFS' regarding taste; he didn't say anything about whether C++ itself does or does not have taste... (I actually think it does in some areas, and lacking in others, but that's another issue..) -- ProgrammerX

A lot of the most elegant parts of C++ aren't apparent until you actually experience the problems they are meant to fix. Because the language isn't proprietary, the creators/designers tried more to solve real-world problems than make things look nice on the surface. Sure C++ isn't perfect, but when you really get down to it, it does a lot of things right that are awkward/impossible in other languages. In other words, the truly breathtaking hacks of C++ don't bite until you actually try and USE it to get something done. Because the creators/designers completely ignored the decade of experience of those who came before them, and because they didn't understand why Lisp, Simula and Smalltalk made the decisions they made, the creators of C++ had to pile hack upon hack upon hack to get even basic functionality working. The astonishing thing - a true testament to the power of both C and the object-oriented paradigm - is that anybody is able to get anything done with the "language" at all.

Ask yourself one question: Why do many people prefer C++ to Lisp, Simula or Smalltalk?

The handful of people I know who prefer C++ to Lisp, Simula or Smalltalk tell me it's because they feel more employable.

Do you think it is because they think the other languages are better for the task? No! If it was, they would use them, instead.

I'm not aware of any way to use Simula today (2004). I know of very few shops where a developer could use Lisp. The situation is a little better with Smalltalk, but seems to be deteriorating. The overwhelming majority of employers force language choices on their developers, not vice-versa.

C++ is a Multi Paradigm Programming Language (with support for procedural, OO, generic, and, especially with libraries, functional programming), rather than just OO or just functional programming. I know. It slices, it dices, it even juliennes.

What I find a little strange is that, like many C++ programmers, a number of Lisp advocates appear bright, yet seem to be unable (or unwilling) to understand why a language like C++ is designed the way it is. If you want Lisp, use Lisp. As Bjarne Stroustrup has said, something like "C++ isn't Smalltalk. Smalltalk is the best Smalltalk." C++ is designed the way it is for a reason. Those may be reasons for using C++, rather than e.g. Lisp, for a project. The language chosen for something may depend on many factors, and good programmers typically know several languages.

[BTW, it is possible to do Lisp Programming with C++, e.g., with Inte Lib. But, hmm, I don't quite remember a language (other than C++) which could allow C++ programming within it.]

People who consider the C++ design as "hacks" appear ignorant of the design and evolution of the language. It evolved from another successful language, C, with influence from Smalltalk (OO), and later got support for generic programming (templates), etc.

[Translation: People who consider C++ piecemeal evolution as piecemeal evolution appear ignorant of the piecemeal evolution of the language. It was piecemeal evolved from another language, C, with influence from Smalltalk (OO), and later had generic programming (templates), etc. stapled to it.]

I find it an elegant language. Yes, I'm familiar with languages like Smalltalk, Lisp or Haskell. Yet, C++ is my favourite language. Nowadays, I use PHP for web applications. Use the right tool for the job.

I'm reminded of Bjarne Stroustrup's quote: "There are two kinds of languages: The ones everybody bicker about, and the ones nobody uses." :)

I find it rather amazing that especially Lisp-fans (but also some Smalltalk fans) jump over each other to criticize C++. You won't find that in the C++ community, which I find liberatingly free of fanatics. If you like Lisp or Smalltalk then by all means use it. But if you think that the thousands of C++ programmers, many of them highly intelligent and well versed in other languages, including functional programming and OO, use C++ because they don't know any better, then you're in a state of deep denial.

Do you define "fanatic" to mean someone who disagrees with you?

[I would define "fanatic" to include those who imply, as certain Smug Lisp Weenies and Smug Smalltalk Weenies often like to do - both in this wiki and elsewhere, that C++ programmers who like C++ do so because they're "stupid" - either due to inexposure to Lisp/Smalltalk/whatever else, or a failure to fully grok Lisp/Smalltalk. It's the old If You Dont Like It You Dont Understand It fallacy. And it's utter BS.

I have lots of nasty things to say bout C++; and I consider myself one of its defenders. It's got lots of warts and sharp edges, damn sure. I like Smalltalk and other languages; they have their place.

But so does C++. Despite its warts, I like it and get lots of stuff done in it. So there. :) ]

People may have different preferences. Some may find it easier to think in terms of imperative or iterative programming, others declarative or recursive. It may also depend on the context, including the language. What I especially like about C++ is that it gives me all these styles or paradigms, and more.

All this criticism of C++ and other popular languages by proponents of rarely used languages sounds like jealousy, to me. Again, it's not because C++ fans hasn't "understood" things like functional programming. I find some FP-concepts interesting (such as lambda, higher-order functions, currying and pattern matching), but it can be done in C++, as well, with a suitable library.

Oh, and to the posting below:

"Bjarne Stroustrup didn't understand garbage collectors and had already made the entire edifice so byzantine that any reasonable garbage collector was impossible to build anyway."

From The Design And Evolution Of Cpp: "garbage collection would make C++ unsuitable for many of the low-level tasks for which it was intended.... I am fully convinced that had garbage collection been an integral part of C++ originally, C++ would have been stillborn"

Your point being? It seems to me that your quote from The Design And Evolution Of Cpp confirms how poorly Bjarne Stroustrup understood garbage collectors. Both statements say the same thing: Cee Plus Plus is incompatible with good garbage collection. Perhaps you should read the book before evaluating Bjarne Stroustrup's level of understanding. The C++ philosophy is, "you only pay for what you use". If you want a garbage collector, you can use one. If not, you don't suffer the consequences of being forced to use one (which in Java's case includes no destructors - thus breaking the infinitely more valuable Resource Acquisition Is Initialization idiom).

So much for not understanding garbage collection. Besides, if you want GC for C++, there are several available. It's not "impossible to build", at all. Also, there are programming idioms where you typically don't need it, and thus can avoid its overhead (such as using Value Objects).

This has already been addressed at length. It's true that several are available. None of them offer the efficiency of the best gc's in Java, Smalltalk or Lisp, or at least none of them do so while preserving the Cee Plus Plus requirements for calling destructors.

Incidentally, Smug Lisp Weenies have their own page.

[There are many programming tasks for which using a Garbage Collector is indeed inappropriate - I wouldn't let one near a Real Time system, for instance; nor a deeply Embedded System where memory is a scarce resource and the several-times multiple of the Working Set that many modern GC algorithms need to function efficiently, simply isn't available. C++ is widely deployed in both types of systems.]

''Does a chip wired into the guts of a Tektronix oscilloscope as a "deeply embedded system where memory is a scarce resource" count as a "programming task for which using a Garbage Collector is indeed inappropriate"?

[Actually, that's more than a "chip wired into the guts"; that's a Motorola 68k processor of respectable vintage, with a fair bit of memory, and lots of custom acquisition hardware. Quite a competent bit of processing power for the time - hardly the equivalent of running Smalltalk on, say, an 8051.

The UI of the Tek 11K scope, which was what Tektronix Inc implemented in Smalltalk, is an appropriate application of Smalltalk. The acquisition system etc. - which is real time (not sure how hard) - wasn't written in Smalltalk; it was written in C. And the C stuff had its own memory pool, so that the acquisition system couldn't be indefinitely blocked by garbage collection cycles.

Perhaps Ward or someone who worked on the 11k could comment further - but it had a fair bit of memory for the time, IIRC. Enough to support a Smalltalk implementation.]

In the extra 18 months it takes to get virtually ANY Cee Plus Plus application working (in comparison to Smalltalk), the available memory generally doubles anyway because of Moore's law.

[The 18 months claim smells like BS to me; the actual gap (if any) will doubtless vary based on the skills of the team, the size and scope of the project, the availability of tools and libraries, the application domain, and a whole host of other stuff. If you know a paper demonstrating that Smalltalk teams can consistently outperform C++ teams, point me to it. For some application domains (enterprise stuff), it wouldn't at all surprise me - C++ has long been a poor choice for enterprise software; with several other languages besides Smalltalk also being a better choice. But an unqualified "18 months" claim simply flunks the smell test.]

This claim is just Cee Plus Plus marketing hype.

[Hype by whom? Nobody is getting rich selling C++ implementations - of the two leading implementations of the language, one (Gnu Cpp) is Free Software and the other (Visual C++) is widely achieving second-class status from the vendor in favor of the Dot Net platform. AT&T certainly isn't out there peddling "marketing hype". The remaining handful of compiler vendors out there target niche markets; and certainly aren't engaged in a diabolical plot to hold back Smalltalk.]

The observation that the C++ community widely deploys applications says only that the suits successfully steamrolled junk into the market.

[Or, it says that the language is actually useful. I don't think C++ is particularly great; however I do think it is useful. And the rants of "C++ is only used because of suits/management incompetence/marketing savvy, and for no other reason" are more BS. It gets used because a) it solves people's problems; b) it's widely available and has been for years, c) it (along with C) is the systems Language Of Choice for the two dominant computing platforms today (Windows and Unix/Linux), and d) there are tons of libraries for it, and e) it was able to leverage the enormous C community.]

The more relevant question is how does C++ compare with Smalltalk in such cases.''

[For many cases, Smalltalk is clearly a better choice. For others, it's not. You'll notice that despite increases in CPU power and memory afforded by Moores Law, Tek hasn't done anything with Smalltalk in years. Part of that was likely politics (Tek, until recently, has had a hardware-centric culture that for a long time resisted even C++ - who needs that sissy OO stuff), part of that was the difficulty with keeping the Smalltalk environment running as the underlying hardware platform migrated with changes in technology.]

[And, it's also widely used to implement garbage collectors and runtimes for higher-level languages.] So what? This is just an abstraction-level confusion. [Not a confusion; instead a point. At some point, Virtual Machines and the like need to be implemented in a systems-level programming language. While I suppose one could try and implement a JVM in Java or a Smalltalk VM in Smalltalk - and that might be useful for debugging or certain things - at some point the chicken-egg cycle must be broken.]

-- Terje Slettebo

C++ is not for everyone, or every project. However, C++ is the logical answer to a series of questions - in other words, given the set of requirements, C++ is a reasonable solution. If you don't understand the requirements, you won't understand C++; if these requirement aren't important to you, C++ probably won't be, either. If you are curious, read The Design And Evolution Of Cpp. If you aren't, quit complaining about C++.

Cee Plus Plus is the result of a cascade of implications of several horrifically bad design decisions, heavily influenced by the arrogance, ignorance, and intellectual sloth of the person and community that produced the sorry mess. And so I enthusiastically agree with you that "C++ is not for everyone, or every project.", and I even agree with you that "C++ is the logical answer to a series of questions." Unfortunately, C++ is the result of incorrect answers to that series of questions. Cee Plus Plus was one of a group of C derivatives, including Objective Cee, Object Cee (from Apple), and numerous home-brew preprocessors (including one I wrote) that used arrays of function pointers to accomplish method dispatch. In such systems, each method name has to be mapped onto an offset into the array that contains the corresponding function pointer. In order to accomplish this mapping, a name scope must be determined for the method name. The design decision taken by Bjarne Stroustrup was to make the scope global, resulting in a slight performance increase, and also resulting in a requirement that every class in the ancestor chain be recompiled anytime any class in the chain is modified. Similar decisions were taken about object "purity" (Bjarne Stroustrup was unable or unwilling to work out how to embed native types in a pure object pointer representation, ala Smalltalk Language), resulting in the proliferation of "operators" versus methods, "primitive types" versus classes, and so on. Bjarne Stroustrup didn't understand and didn't want to understand metastructure (and his earlier decisions added so much gratuitous complexity that any metastructure would have been immensely more difficult), and so class objects and a viable runtime model fell by the wayside. With no class objects and no metastructure, "constructors" and "destructors" became necessary. Like the metastructure decision, Bjarne Stroustrup didn't understand garbage collectors and had already made the entire edifice so byzantine that any reasonable garbage collector was impossible to build anyway. I don't need to read a book about presenting some sanitized reconstruction of the history -- I was in the middle of the language wars while they were being fought.

[sung to the tune of 'Veteran of the Psychic Wars' by B.O.C.]

(It seems like some topics on the Wiki always bring up one of these "yes it is - no it isn't" levels of discussion everywhere it's mentioned. Am I ever sick of hearing about Emacs ;-)

I can see why C++ would not be someone's first choice, and for some people, would never be considered an option. It's not my first choice, either, but not every tool is appropriate for every job. However, I would much rather be using C++ than what I'm currently using in one of my projects (yet-another-C-plus-minus toolkit like you mentioned).

I don't believe that Bjarne made the choices he made because he didn't know what he was doing. I think he made different choices than you would have made because his priorities were different from yours.

C++ is a large, very expressive, powerful, and low-level language. It has a lot of quirks and darks corners. It is often misused, and often the wrong choice, but it is not 'unusable'. For some purposes, it remains the best choice - for a wide variety of reasons. C++ isn't smalltalk, but it was never intended to be.

[And therein lies the problem. C++ should have been Small Talk. In fact, it should have been Objective-C. I know Bjarne wanted Simula rather than Small Talk, and he made all of his language design decisions consciously. Unlike some, I do not accuse Bjarne of ignorance. I do accuse him of making simple bad decisions. (N.B. I am a late convert to Objective Cee, Ruby Language, and dynamic languages in general -- my background is C++).]

Actually, if you read his book The Design And Evolution Of Cpp, he laments the fact that some of his language features and choices were political (due to the ISO process) rather than technical.

If Cee Plus Plus had been designed as a clone of Smalltalk, it probably would have been stillborn. And to quote Bjarne, if you want Smalltalk, use Smalltalk. (Likewise for Objective Cee, which would have been stillborn had it not been for the Ne Xt and Mac Osx...and is missing a lot of the more interesting features of Smalltalk.) There are those among us who like Cee Plus Plus, for all its warts - and we're quite happy to use that. Li

I guess Objective C is missing blocks, but what are these other Smalltalk features that are missing? (Given that Smalltalk is such a small language, it's hard to imagine that "a lot" of features could be missing; there aren't "a lot" to start with.)

Garbage Collection? It may have that nowadays; for a long time though it did not. (And if it does have GC; how does that interact with the C layer? Is free() now a do-nothing function?) Also, can one mutate the core classes in the Objective Cee library in the same manner one can mutate a Smalltalk image?

Apple's implementation uses Reference Counting ([object retain], [object release], and [object autorelease], which is a form of delayed release, and will release the reference at the end of one of the containing scopes (the cocoa framework puts an autorelease pool in the main event-handling loop, iirc)). I'm not familiar with Small Talk, but you can add methods to any class using a feature called Categories, which are described pretty well on the Objective Cee page.

[I actually have read The Design And Evolution Of Cpp, and I actually do like it, and I actually do like C++, and I do respect Bjarne's skills etc. But the total amount of programmer productivity lost by using C++ instead of Objective-C is simply astounding. And to respond to Bjarne's assertion: Small Talk could be said to be unsuitable for systems programming for the same sort of reasons that he found Simula unsuitable. I used to be a C++ lover, no question. Unlike many, though, I never stopped searching for better. Between Ruby Language and Objective Cee, I'm convinced that dynamic languages are the way to go if you want speedy development and reusable component libraries with RRBC. Ever written a modern Cocoa application?]

Why do many people prefer C++ to Lisp [or] Smalltalk?

1. C++ does not have garbage collection. When a programmer states that an object is not needed anymore, the memory becomes available again. A programmer (and a user) can be confident about how long a delay there will be between steps, because there will not be (long) garbage collection steps at irregular intervals. Anyone who played xconq on an early 1990s work-station has experienced the frustration of waiting for garbage collection.

This is less a concern now than with efficient, predictable, iterative garbage collection now being available. However, most people who fear garbage collection now have that fear embedded deep into their psyche. We'll need to wait a few generations for it to diminish.

Oh, and C++ garbage collectors DO exist, just in case you're interested. Google for them. However, they aren't as efficient as is garbage collection in languages designed for it.

2. C++ has more security than Smalltalk. Yes, C++ lets the programmer overload most features, but the programmer can have some confidence that public, private, and friend actually mean something.

#define private public, #define protected public, unsigned char* pX = reinterpret_cast(&(obj))+44,...

Which is why maintenance programmers look for the Cee Preprocessor Statements when they are debugging.

3. C++ is typed, but with escape hatches. The programmer has frequent reminders (in the code) about what the type of each item is.

This one [was] incorrect. C++ is statically typed, but not strongly typed. But, even ignoring the use of casting, there is a major issue preventing it from being strongly typed: covariant argument parameters for virtual methods.

class A { public: virtual ~A() {} virtual void action(A& a) {... do something ...} }; class B : public A { int m_nValue; public: // action with covariant parameters. virtual void action(B& b) {... do something with m_nValue and b.m_nValue ...} }; void test() { A* pA = new A(); A* pB = new B(); pB->action(*pA); // <-- no typecheck error! and will use B's action and try to use (*pA).m_nValue }

The above assertion of a typecheck error is incorrect. The code doesn't do what you think it does. B::action does not override A::action; it's a distinct member function with a distinct signature. It overloads, rather than overrides A::action. In C++, a member function's signature is its name and its list or parameter types. Since the signatures of A:action and B:action are distinct, overriding does not occur in this example. Another consequence is that C++ has only covariance of function return types, which is safe. -- Dan Muller

Is that so? I'll run some code to double-check, but it leaves me curious as to why this produces a typing error:

void test() { A* pA = new A(); B* pB = new B(); pB->action(*pA); // <-- typecheck error! A::action not called based on distinct signature. }

Hmm, sorry, my saying that B::action() overloads A::action() was an oversimplification. In this second example, pB is now of type B. B's action() actually hides A's because the names are the same (even though the signatures differ). This flies in the face of my statement about signatures, but this behavior is by design in C++, and helps prevent common programming mistakes. You can overcome the hiding by adding "using A::action;" to B's declaration, which has the effect of bringing A::action() explicitly into the scope of B. -- DanM

Thanks.

4. C++ supports const correctness.

Useful to avoid accidents, but not very strict around 'char*' in most compilers I've seen.

char* test() { return "Hello, World!";}

5. Similar to Lisp or Smalltalk, but unlike C, it is possible to write C++ without explicitly using pointers. The pointers needed to interpret the command line can be wrapped up in a short function or two, including the main() function. After that, the code can use references, not pointers.

True only of some programs. If you need to use collections of virtual objects, you're stuck with pointers.

What's a "virtual object"? To make polymorphic collections of objects, you typically need to use pointers. (Consistent use of smart pointers eliminates many of the concerns about memory management cited on this page.) -- DanM

Interface, ABC, whatnot. You don't actually have a collection of abstract classes (in fact, there are no 'classes' at all in the live collection-object), and the objects themselves aren't taking many forms over the course of their life (not really 'polymorphic'), so... 'virtual object'.

6. C++ has more syntactic sugar than Lisp. Yes, C++ overloads many features -- but Lisp puts most of those overloads on just two characters, "(" and ")". That much overloading makes Lisp unacceptable to many people.

Lisp lets you grind your own syntactic sugar....

7. C++ has sensible idioms for array-dereferencing. Although Lisp has the (nth) command, use of car and cdr is much more common -- and much harder to read.

Oh, who has problems with caaddar? ;-) I'd note that car and cdr are for lists, not arrays.

Agreed. CAR and CDR are for lists, and are not actually used that much in modern Common Lisp programming. Array elements are accessed using AREF: (aref list i j k ...). Very sensible. -- DanM

8. C++ lets the programmer declare local variables near the point of use, not just in the function header.

Lisp doesn't stop you from using a 'let' or 'letrec' if you want it. I'm not sure about Small Talk.

9. C++ has destructors and supports RAII (Resource Acquisition Is Initialization). In here, groups.google.co.in Bjarne Stroustrup talks about how RAII was (one of) the first thing he added to C when making C++. This is the single thing that puts C++ above other languages in my personal preference list.

Wow, what a pointless discussion. If your problem domain allows you to use Lisp, Smalltalk, Ruby, or even Objective C, go ahead, and don't waste time even considering C++. C++ is a valid candidate in those cases where the only alternative would be C. In those cases, if you only can get mediocre programmers, stick with C and take the hit. (Same if your problem is quite simple -- your hit will be minimal.) Otherwise, Bjarne Stroustrup's decisions make a lot of sense, and C++ will give you more maintainable, more evolvable software. There is currently no mainstream alternative (although several languages are on the boundary, such as D and OCaml).

Hogwash -- when Oberon-2 was introduced, it offered everything salient that C++ offered at the time, and with fewer keywords, and more. It offered very fast execution (run-time array bounds and nil pointer checks could be turned off via a compiler option), safe execution (or left on just as easily), is statically, strongly typed, modern variants now also offer generics (however, Turbo-C++, et. al. equally didn't offer templates back in the day either), and nearly all Oberon environments I've seen allows you to control the GC in various ways for real-time purposes. Indeed, Oberon (like Modula-2) appears to be used in a number of European real-time projects.

Functionally, only the syntax of the language differed. People apparently hated the mandated use of all-uppercase keywords, hated putting types after variable names instead of before, and just generally couldn't bring themselves to be found in public after having worked with Oberon. From a bullet-list point of view, comparing feature against feature, for all features that actually contribute tangibly towards a successful project, it is every bit as much a valid candidate anywhere you would think of applying C++, and it provides substantially clearer source code, superior modularity, and type-safety.

C++ was chosen as the language of the new generation of systems programming languages. This was a mistake of monumental proportions. C's success can, at least in part, be attributed to the mistakes of Pascal. Those mistakes have since been fixed. But, it's too late -- the burgeoning hegemony of harder to read, harder to parse, overly complicated, and otherwise Fad Ware programming languages, such as C++, all in the futile attempts at backward compatibility, have won the war against simple sanity and common sense.

{The Good Enough is the enemy of the Right Thing. I will not dispute that Oberon very likely would have been a much better choice than C++ for systems programming (not that there's any objective measure for that assertion). But it doesn't matter at this point; overthrowing any established system with its inertia requires a solution remarkably better than the one that exists, such that (a) people fight inertia to use it, and (b) the existing solution can't "hack in" some slow, awkward incremental improvement that captures the same features in a 'Good Enough' fashion to keep people on its side. It's a lesson that all Language Designers should learn from, especially since backwards compatibility is such an enormous hassle to support when attempting to 'clean up' any language (not so bad if you're okay with language Feature Creep, like Perl). Get it right, right now, or know that you'll have to make do with Good Enough until someone invents something much better; Yag Ni doesn't apply to language design, which is why Pascal failed and took Oberon and its other incremental successors down with it.}

This entire issue is a little odd, languages are simply tools at our disposal, a skilled carpenter could attempt to use his saw to lever out a bent nail but it would take a lot more time and lateral thinking (not that this isn't fun), but the claw hammer is just lying there doing nothing. Every language has its time and place; if I want lightning fast performance with the convenience of the OO paradigm (say for a game) I'll use C++; if I'm building a restaurant billing system, I'll probably use a managed language where I don't have to worry about a hanging pointer taking the system down on a busy friday night. I don't think it is possible to create a magic-bullet language and no-one should try; universal remotes never work quite right, and neither would a universal language. C++ definitely has its place and in that place it shines brightly... usually your games collection ;)

[Reply in Pick The Right Tool For The Job]

It's rather sad and odd to say nowadays that one of the strongest point of C++ is his compatibility with C. Removing compatibility with C from the new standard would probably kill the language. Sad also to say that C++ is like a farm where the cows escaped out of desperation. There are nice little niches nowadays such as gaming, compilers, computational stuff, real time, network, Os, hardware drivers. But the biggest part of the market, which is the enterprise market, escaped to java and later on to others in order to make developers a commodity.

The standard is awfully large and still awfully weak. The availability of libraries, made out of real C++ is so little, and still all rely upon C libraries. In the standard there is yet no web, no xml, no gc, no User Interface, no test driven development, no metadata programming, and this is often not even in boost.

If you hire C++ programmers, you better go to Lourdes first, and then please have a read to the bible in the paragraphs about the babel tower. Programmers: they will not even talk the same language, they will fight to death for design and they will end up in a bizantine solution.

One day god comes down and tells to you that you are from now on the boss of IBM, if you just have everybody develop C++, Money will flood from the sky.

First of all you need something equivalent to a C++ university. Each of your half a million employees will spend some time in your university, from a couple of months to a couple of years of training with exams and usual stuff (even sales people and secretaries will need training).

Then you will need at least a 100 man years for rebuilding a compiler from scratch (there are people theorizing to start out compiler development from the generic type system perspective instead of the usual red dragon perspective) plus some other 1000 man years for building up a decent set of libraries and tools. Take in consideration that STL alone dates back to the 70s and became visible in the 90s.

Having spent this money then the most difficult task is there, convince everybody that your libraries and compiler, i.e. your standard proposal is the best on earth, which to be optimistic is another 1000 man years (imagine people doing scientific publications, improving the software and so on so forth).

Considering just software development related people, 100Keur gross / man year, we have now spent at least 3000 man years, which is 300 billions euros. This number is not actually so big if you consider that the apollo project was $22.718 billion across 13 years.

Oops, I forgot one thing, you end up bankrupt still, but god is at least happy, the standard is made on purpose to make all the work you have done a commodity.

The worse part of this story is that I still love C++, and I would love to make it better.

See: Cpp Standard, Cee Plus Plus Idioms, Late Cee Plus Plus, Early Cee Plus Plus, Operator Overloading

Category Programming Language Category Cpp, Category Considered Harmful, Category Considered Useful

See original on c2.com