Cpp Bashing

The increasingly popular sport of 'having a go' at the C++ language. Usually along the lines of:

The reality is: C++ is a mature, widely used, multi-paradigm language. It isn't the tool for every job, but then nothing is.

It is still the tool when performance is an issue and you can't do it in asm.

-- I'd say as much C and as little C++ as possible is the tool "when performance is an issue."

If you write in good StlStyle, C++ is at least as fast as C while vastly more maintainable. The problem with C++ is learning curve; to really get proficient in the language is extremely difficult, so most folk can't write "good C++", nor tell the difference between good and bad C++. So ... AlternateHardAndSoftLayers, and hire real C++ talent to ReFactor/optimize the hard layers.

In my opinion, the term StlStyle is ConsideredHarmful. There is no such thing as StlStyle and one can achieve the same performance benefits by simply using GenericProgramming techniques in CeePlusPlus. It need not be StlStyle, that is like saying libc-style when one means modular.

Actually, one could just as well use AdaLanguage or ObjectPascal. In most cases, they share their back-end code generator with C++, so you get basically the same bits. The only thing that's different is that you substitute begin...end for {} and compilation times are cut drastically because you don't need to include enormous .h files. But long compilation times protect you against RSI.

A lot of companies use it to build very large, successful systems: such as Microsoft and Windows 2000.

Perhaps a bit controversial to call it "..the tool when..", since at the end of the day personal preference/bias pretty well rules out anything being "the" language for general classes of jobs.

Moreover, many people would consider the fact that Windows 2000 is implemented in it actually negative evidence; systems with a much smaller memory footprint and similar functionality have been implemented in SmallTalk and ObjectiveCee (NextStep).

Apples & Oranges. Windows 2000 is an OS and SmallTalk & NextStep are development environments built on top of an OS. (nothing against SmallTalk and NextStep, however) Reread the statement: it says "systems ... implemented in SmallTalk....". And NextStep is an OS.

That's just marketing blurb. In the olden days, Windows was a shell around DOS. One could bundle a Linux kernel with SqueakSmalltalk and call the result an OS. It would still be much smaller than Windows 2000. BTW you can even get rid of the Linux kernel and simply provide primitives for Squeak to access drivers etc. Whats more, somebody has actually done this

Neither Smalltalk or NextStep compare very well on the widely used point! There's another one to add to the list: 'long compile times'. This is of course a design trade-off rather than language flaw

Windows 2000 doesnt really count on the widely used front either, although I'm sure it will get there with time. More controversial is the assertion above that it is (already) successful, although I'd agree previous Windows have been, in terms of units shifted. I dont see this as a problem with your case (that CeePlusPlus has been used successfully in larges systems), I just think W2K is a poor example to be making your case with.

Actually Windows NT and Windows 2000 are mostly implemented in C, not C++.

How about BeOS as a case for C++? Most people I know who program it love the API, it's very stable, very quick.

Fair point. I'm willing to say 'Windows' rather than Windows 2000. But IMHO, Windows 2000 will undoubtedly be successful because NT4 has been, and Windows 2000 is a lot better! Oh, and MS know how to sell. Although, I'm going OT.

The point is:

Stroustrup maintains that there is nothing he would change.

C++ was developed with two major design constraints:

  1. As much backwards-compatibility with C as is practical. Therefore, for example...
    • C++ has pointers (and all the dangers associated with them) because C has pointers.
    • C++ syntax is even more cryptic than C's, because the designers didn't want to add too many keywords to the language.
  2. You don't pay for what you don't use. Therefore, for example...
    • You have to explicitly declare which functions can be polymorphic, because if subclasses could override any function defined in a superclass, the compiler would have to add a run-time check to every function call. [This could easily be solved if we had a more intelligent linker, that could decide if a function should be virtual at link time. The real reason why in C++ this burden is shifted to the programmer is because Soustrup considered it important that the standard unix linkers could still be used for C++. This is also the reason why templates are so painful in C++ -- a C++-aware linker could simplify this a lot more. (Intelligent linker can't solve all the problems, it won't help you with shared libraries)]

Given those design constraints, I don't see how C++ could be any better than it is.

To offer a contrary point of view: languages exist that are better than C++ at point 1--ObjectiveCee, for example, has no trouble #including arbitrary C headers, something modern C++ will not do--and point 2 is of debatable utility; the performance advantages can be recovered relatively easily but the awkwardness of expressing legitimate concepts remains. ObjectiveCee, for example, will permit you to get a function pointer to a method, then call that method as many times as you like without incurring lookup each time. -- GrahamHughes

You can do the function-pointer trick in C++, too. But why would you? It's a silly optimization. Virtual method lookups are seldom -- I say seldom, but in my experience never -- the performance bottleneck.

Virtual method lookups are often deadly in numerical programming. You would love to have an abstract base class for, say, Matrix, but it costs too much. Templates work well here, but it isn't always pretty.

Numerical analysis in C++ is slower than languages built specifically for numerical analysis because C++ copies objects around on the stack a lot. Even with pass-by-reference, the in-built optimisations of numerical analysis languages out perform C++. Templates work because all the computation is done by the compiler. Anyway, the libraries exist because of the necessity to interact with the rest of the C++ program.

C++ does not copy objects on the stack a lot; some C++ programmers may choose to program that way, but it is not a language requirement. For better or worse, C++ gives the programmer control over memory allocation; if one wants to be a C++ programmer, one must learn how memory allocation works.

Actually, template-based C++-code now tends to outperform Fortran in numerical calculations. Other (more recent) numerical analysis languages often generate C++ code. Template metaprogramming can be used to optimize calculations like 

 a = a * b + c;
where a, b and c are, for example, quadratic matrices. A clever template library and an optimising compiler can turn this into something like 

 inplace_multiply_and_add(a, b, c);
which means that you can use straightforward mathematical syntax and still get optimum performance without any need to "copy objects around on the stack a lot". For example, see http://oonumerics.org/blitz -- ArneVogel

You don't pay for what you don't use. -- This is often quoted but the design principle is more like, "You don't pay for what you don't ask for." The defaults favour speed.

To go back to that polymorphic functions example... in Java too, you don't have to pay for polymorphic dispatch if you don't use it. However, it is on by default - you get it even if you don't ask for it, unless you ask not to get it. In C++ the default is the other way around.

The C++ defaults favour efficiency over flexibility. This is goes against experience which says that 80% of the code will not affect the overall speed and therefore does not need to be efficient. It is premature optimisation wholesale. -- DaveHarris

Comments moved from ConstCorrectness:

I used to program in C++, which makes this comment, I hope, far less bigoted than it may appear. I hope it turns out that C++ really is a hell of a lot faster than alternatives, and that the programs being written in it really needed that kind of speed, because it is really one seriously inconvenient language. Are you guys sure you're not using it just to show how tough you are? --RonJeffries

See the geek girls swoon when you flex your PartialTemplateSpecialization?.

In my many years of writing C and C++ programs I have, on a number of occasions, remarked that "It doesn't really make sense to develop business functionality in C/C++." (...because there's too much emphasis on the technical details, and a lack of common support for abstractions of most use to business -- like fixed place decimal arithmetic with a predictable number of significant decimal places, for instance.)

However, I keep doing it -- because that's what the customers want. (And what would you have me do, program in VisualBasic??? Ick! ;-) -- JeffGrigg

I've just been porting a C program to BeOS, which needs to use C++ for the user interface code. This is all well and good, but every time I think "C++ might not be as bad as I thought it was", it hits me over the head with some incompatability. Starting with "template" being a reserved word (okay, fix one struct), to struct names being typedefed by the compiler (okay, change "typedef struct foo { ... } *foo;" to be an anonymous struct...), to anonymous structs being given different names in different files, and the typedef doesn't enter into it (sigh, re-name the struct I just made anonymous, which is annoying. If I'd thought about it, I might have used a Factory, but that would have been just as much of a hack, and it would have had to be declared extern "C" to avoid the typesafe linkage, itself a misfeature. I may still do this, as the struct really doesn't want a name anymore). The core language may actually be good, but it is surrounded by such a collection of misfeatures as to make it virtually unusable for large projects, especially those with a large base of C code.

Starting with "template" being a reserved word

Complaining because they added new reserved words when they added more functionality is a bit weak. The other option is to dynamically compute everything from a base set of primitives like Smalltalk or Self.

typedef struct foo { ... } *foo;

This is lying to your clients. foos are structs, not pointers. If you want a pointer to a struct, you will still need to access the base type (the actual struct foo) in order to allocate the memory for a foo, even if you use foo bar = (foo)malloc( sizeof *bar ); Of course, this random mixing of pointers with normal types is pretty poor style. If you have to, do something like:

typedef struct foo { ... } *pFoo;

to anonymous structs being given different names in different files

That makes no sense. Anonymous structs have no name, let alone "different" names. You cannot uniquely identify the type as you seem to want to do; you need a unique moniker for the type. You have to name it.

"How can you hate C++? It's just a tool." --StephenFraser? at XpTwoThousand(paraphrased by JasonYip)

Reminded me of DeNiro? in Ronin... So I no longer hate C++, but I don't have to like it. --JasonYip

I hate C++ very much, not because it lacks feature x, but because code that I write in C++ has a nasty habit of just not working, without any indication of why it isn't working. Java never gives me that trouble, and even when my Java code doesn't work, the tools available for debugging it (namely NetBeans' debugger) are so vastly superior to anything that I have found for C++ that fixing my problem is simple. And, seriously people, a language's speed is becoming less relevant with each new increase in processor speed, I would much rather program in a "slow" language that works and makes sense than in an unintuitive, convoluted piece of shit like C++. --Mason

C++ is not my favorite language, but code that I write in C++ usually works right, and when it fails, I usually find the problem pretty quickly. So it's not the language's fault, dude. When you can afford the speed hit, by all means use Java. But don't buy that old saw about how faster processors will make fast program unnecessary -- as the processors get faster, the demand for features and capacity of software goes up almost as fast. -- DanMuller

The whole idea that we'll all be saved by increasingly faster processors is becoming more and more ridiculous. The reality is that engineers are having an increasingly difficult time making faster processors, and have instead turned to multi-core architectures, which is why parallel programming is becoming more and more important. C++ will always be an important language because it is designed for efficiency, and gives the programmer more control over details of implementation. Admittedly, the lack of native threading support in C++ has been a serious problem, but this has been mitigated somewhat by portable libraries such as boost threads (see BoostLibraries). Of course, this will become a non-issue with the advent of C++11 (CeePlusPlusEleven).

Finally, I have never found C++ particularly more difficult to write than something like Java or C#, especially with modern STL-based programming techniques. RAII style programming all but eliminates memory leaks, and even introduces advantages over memory-managed languages like Java which don't have destructors and therefore require you to remember to explicitly release resources other than memory, such as open sockets or files. All in all, I've always found C++ to the best overall language available for developing large-scale systems. -Charles Salvia

Yossi Kreinin deserves special mention as possibly the greatest C++ basher of all time. His C++ FQA Lite (Frequently Questioned Answers) is a lengthy point-by-point rebuttal of (attack on?) the C++ FAQ Lite. He's often guilty of presenting his biases as facts but he succeeds at illuminating some very real impracticalities of the language. The best part is the summary -- food for thought and worth reading:

http://yosefk.com/c++fqa/defective.html

From the above link, Kreinin's main C++ criticisms:

CategoryCpp

EditText of this page (last edited September 27, 2014) or FindPage with title or text search