When Should We Use Cee Plus Plus

WhenShouldWeUseCeePlusPlus? In combination with scripting languages, as a way to AlternateHardAndSoftLayers. The most comely combo for me right now is ZopeApplicationServer + PythonLanguage + CeePlusPlus, though of course the most popular way is ASP + VB + COM + CeePlusPlus.

You can, if you are perverse enough, build large systems in CeePlusPlus. In fact, most of the systems I see these days are either that or JavaLanguage, which is just as bad, and often worse for this (See WhenShouldWeUseJava). But it's an ugly habit and does you no credit in the eyes of the civilized folk. The right place for CeePlusPlus is those little bottlenecks you detect that you need to make go fast. (not that C++ is always fast)

CeePlusPlus's great advantage is over C (Speak for yourself! -- TomStambaugh). Any time you're tempted to use C, use CeePlusPlus instead. The trouble is the language creators (BjarneStroustrup & AlexanderStepanov) are perverts of the ilk described in the second paragraph above, and go through hoops of fire to try to make the language suitable for building large systems. AlternateHardAndSoftLayers seems not to have been in their thinking.

WhenShouldWeUseCeePlusPlus? For each really large and complex system where also speed is needed, like OSs, office applications, compilers etc. Often those are written in C, but as others pointed out, C++ is the better choice there. If you are not bound to speed, using Java may be an option.

The problem in using CeePlusPlus is, one needs to use an intelligent subset. To find the appropriate subset for one's problem is a tough task which needs a lot experience. That's why CeePlusPlus is that unpopular among many people. It is in no way a perfect language. But it is one of (or may be THE one) programming language with the richest, mightiest set of features - as well as probably the language where you can do the most syntax-correct mistakes. So in the hand of the experienced it is an incredible tool. Just another thought: It is easy (though may be a lot of work) to write a library in CeePlusPlus, which then allows programming "as if" I'd be using Java or Lisp or Perl and a lot more languages. The other way round it is impossible. -- NikolaiPretzell

WhenShouldWeUseCeePlusPlus? When we care about performance, but don't care enough to write it in assembler. (See also: WhenShouldWeUseJava)

When I "care about performance", I put a test harness on my app, find the slow parts, and RefactorMercilessly until they go fast. I haven't done it in JavaLanguage yet, but my experience in Smalltalk, when I've competed against CeePlusPlus teams, is that my app is up, running, optimized, and in use by the client before the CeePlusPlus team has even finished the initial builds. Most of my Smalltalk engagements were from clients who thought that they "cared about performance" and chose CeePlusPlus - I usually got the call about two years later. -- TomStambaugh

No knock to your smalltalk and refactoring skills Tom, but AlternateHardAndSoftLayers would let you do exactly what you do now, and still meet all the performance goals those C++ guys were supposed to hit. I don't know whether you can easily mate Smalltalk with C++ (The SimplifiedWrapperAndInterfaceGenerator does not do smalltalk.) but I think the opinion above the line above still stands. While we've got you here, though, do you think there's a good reason to prefer SmalltalkInsteadOfPython? -- PeterMerel

The immediate reason for me to prefer SmalltalkInsteadOfPython is that I can then avoid learning YetAnotherLanguage?, which is becoming more and more difficult for me in my advancing senility (especially since my language input port is saturated with JavaLanguage at the moment).

I, too, use CeePlusPlus in the context we're discussing here - what I meant to express is that I only use the "C" portions of it, though. I basically avoid all but the most primitive "object-oriented" stuff in it. -- TomStambaugh

If C++ had a standard, object-oriented, well-documented set of libraries for every possible thing (like Java and Python have) and nice, pleasant, serializable GC objects available (which can be implemented in C++), you might sing a different tune about it. The problem with coding C++ is that you have to hack together objects around a bunch of vendor-specific C-styled (non-OOP) libraries from a hojillion different sources, while the Java and Python coders get it all "BatteriesIncluded?", as the python types say. None of this is because of the weaknesses of the C++ language, but because of the fact that the out-of-box (not to mention Boost) are all focused on speed and expressiveness, instead of being ready-to-use.

You can implement Java-like pleasantness in C++. You can't implement C++-like expressiveness and speed in Java.

There is information about a range of libraries for C++ at CeePlusPlusDotOrg.

And what about the template and generic programming features in the C++ language? How well are they supported in Smalltalk? I take it you've never written a server application? Or never had to do one where price/performance is an issue?

Smalltalk has no notion of templates in the C++ sense, because it doesn't need them; the Collection hierarchy is done just using standard Smalltalk objects, and it seems to do pretty well. Templates are only necessary in statically typed languages. And for the record, I write Web applications. We get hammered periodically, and we like the server to not break in half every time somebody gets interested in something I wrote. The bottleneck has never been my Python code; it has always been in the RelationalDatabase I store the crap in. Gigabit Ethernet? Gee, thanks, does it help Postgres do joins faster? -- GrahamHughes

FWIW you can readily combine C++ StlStyle generic programming with Python data structures. See http://cxx.sourceforge.net/. So there's no good reason to stick with verbose, error-prone C-style C++ when you AlternateHardAndSoftLayers with Python.

Oh, I don't know about that... the forever-and-a-day compile times with anything involving templates, the stunning immaturity of today's template libraries (see Kernighan and Pike's ThePracticeOfProgramming for a good example), the complete inability of today's compilers to generate useful error messages if a template sneezed near the error, the surprising things that happen when you throw exceptions across code that isn't expecting them (even other C++ code), the lack of a name-mangling standard (which makes writing a C++ library that two or more compilers can use impossible) - these are just the implementation problems. I can still come up with reasons to use C. And I hate C. -- GrahamHughes

Hmm. Someone hasn't followed the proliferation of mature cross-platform StlStyle libraries very closely. ObjectSpace, RogueWave, and especially StlPort!

Even better, see BoostLibraries

It is in no way a perfect language. But it is one of (or may be THE one) programming language with the richest, mightiest set of features - as well as probably the language where you can do the most syntax-correct mistakes.

Maybe you should have a look at the ObjectiveCaml language. It is safe (an Ocaml program that compiles is nearly crashproof), far more readable, expressive and powerful than C++, and it is at least as fast (see Doug Bagley's GreatComputerLanguageShootout for an extensive benchmark).

[Well but there's another thing which is significant for me. CeePlusPlus is still able to act as a LowLevelLanguage - that is, it doesn't force us to use a GarbageCollector and, which is even more important, we always know what the result of the compilation will be. And it is definitely the only LowLevelLanguage with such a rich set of features -- AndreyStolyarov]

I started programming in BASIC, then learned Pascal, C, C++ and Java. At this point I thought C++ is a fine tool for almost everything. Of course, that's a misconception, caused by the fact that I didn't know about many other languages. Sure, C++ is a substantial improvement over C or Pascal. It has a much better type system, but not nearly as good as that of the ML family. The compiler does much more checks for you, but not a many as an ML compiler does. STL-style algorithms are elegant, compose easily and can be reused with unprecedented flexibly, but that's nothing compared to higher-order functions. Objects and inheritance are quite nice, but limiting compared to records of functions with lexical closures. The list goes on and on.

Add to that the typical failure mode of C++ programs: SIGSEGV, with absolutely no hint what happened. Sure, it's my own fault, stepping over the bounds of an arrays. But how come I don't overstep arrays in Haskell (where I would get an error message, not a core dump)? These days I'm increasingly convinced, C++ is not nearly high-level enough. Something has to be layered on top of it, be it Python, Tcl, Scheme, Haskell, whatever. But interfacing to C++ is a lot harder than interfacing to plain C. So when I'm writing a program, the bulk will be in Haskell (a personal preference, use whatever floats your boat) with some tight loops or some thin glue to existing systems coded in C. C++ no longer enters the picture, I'm just using the C++ compiler to get some more type checking and a bit relaxed syntax.

So WhenShouldWeUseCeePlusPlus? Probably when nothing else is available.

Interfacing C++ to other languages is possible using the SimplifiedWrapperAndInterfaceGenerator. -- JohnFletcher

CategoryCpp