Was Linus Torvalds Right About C++ Being So Wrong?

Nerval's Lobster writes: Perhaps the most famous rant against C++ came from none other than Linus Torvalds in 2007. "C++ is a horrible language," he wrote, for starters. "It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it." He's not alone: A lot of developers dislike how much C++ can do "behind the scenes" with STL and Boost, leading to potential instability and inefficiency. And yet there's still demand for C++ out there. Over at Dice, Jeff Cogswell argues that C++ doesn't deserve the hatred. "I've witnessed a lot of 'over-engineering' in my life, wherein people would write reusable classes with several layers of inheritance, even though the reusable class wasn't actually used more than once," he wrote. "But I would argue that's the exception, not the norm; when done right, generic programming and other high-level aspects of C++ can provide enormous benefits." Was Linus going overboard?

Comments

Write-only code.

[mellon]

The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

Re:Write-only code.

[Carewolf]

The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.

Less so than C, especially as used in the kernel. Seriously read some of the Linux kernel and compare it with any good C++ project. The kernel loses BADLY. The manually implemented virtual classes are not pretty and not type safe, and neither are all the ugly macros needed to do things that would safe, automatic and easy to read in C++.

Re:Write-only code.

[KermodeBear]

The same applies with Perl. And PHP. And Java. And Go. And Ruby. And Python. And Javascript.

I've also seen good C/C++, PHP, Java, Python, etc.

You can write crappy convoluted code that uses odd, unusual frameworks and features in every language. It isn't the fault of the language - it is the fault of the people (ab)using it.

Re:Write-only code.

[serviscope_minor]

because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year

Give one example of that ever happening. The C++ standards committee is notoriously conservative which is why the language evolves so slowly. This comes across as you just making shit up when you haven't got a clue.

The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways.

That might be *your* problem but it isn't mine. Every decent place (staffed by true scotsmen of course) with project teams has things like coding standards and code reviews.

If your developers are committing crap code to the mainline then the trouble is that (a) your developers and (b) your process sucks. The thing is it will suck in any language.

The library is here: Extended C library, libxc, so help yourself (BSD license)

OK, I'll bite.

Well, if you think having XVEC_DEREF(some_vector, i, float) for resisable arrays but array[i] for builtin ones is better than having array[i] for both, well, then I guess we're just on completely different pages here.

The thing is there's massive syntactic overhead to your code. And the overhead is more like 1000% not 150%.

vector<float> = { 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8, 9.9};

works perfectly in C++, whereas that's 10 lines of C code!

And I was wondering how it worked underneath, and I had to dig into the code. So you're storing pointers to the elements, not the elements themselves! I never even realised that. Wow, so that means you can't even do:

xvector_ins_tail(tfar, &1f);

You have to do:

some_float_which_has_the_same_scope_as_tfar_and_is_never_reused = 1;
if(!xvector_ins_tail(tfar, &some_float...))
{ //Do something error related here //probably a longjmp or goto. //Don't forget to free all that memory!
}

versus:

tfar.push_back(1.5);

It also means you're in nightmare memory management from hell since you now have to manage all those bits of memory by hand.

It *also* means that you have no memory locality since it's a big array of pointers, so performance will almost certainly be bad as well.

The equivalent C++ code to your xvector/main.c is something like:

vector<float> sfar = {1.1, 2.2, ...};
 
for(const auto& f:sfar)
  cout << f << endl;
 
eg_t eg[] = {...};
 
vector<eg_t> teg, sub;
for(const auto& e:eg)
  eg_t.push_back(e);
 
for(auto e:teg)
{
  e.i += 2;
  e.f -= 5.0;
  sub.push_bach(e);
  cout << "Returning " << e.i << " // " << e.f << endl;
}
 
//Well, the nativea bit is basically already working in the C++ code since internally, std::vector uses a native array

And that gets us to line 90 or so. There's more, but you missed the error checking for if something isn't found in the xvector. It also took me a while to verify that all the allocations are matched by the respective free. It would be nearly impossible to be sure for less trivial code.

So, I'm not convinced you've made a case for C over C++ here.

Almost got me

[halivar]

I always get halfway through a Nerval's Lobster summary before my anger/indignation/smug validation gives way to the sad realization that Dice has trolled me yet again.

Yes, he was wrong...

[RailGunner]

If you care about performance, the ability of C++ to "run on the iron" is a valuable tool to have in your arsenal. Add in inline assembler, and IF YOU KNOW WHAT YOU'RE DOING you can write blazing fast code in C++ and still provide a sensible code architecture.

There's no sense in blaming the language for the abuses developers have written -- you might as well indict English for the horrible spelling and grammar of many Americans...

If you know what you're doing, C++ is a terrific, powerful language suitable for a plethora of projects. On the other hand, if you don't know what you're doing, well, I guess there's Visual Basic or C#.

Re:No

[boristhespider]

A clickbait article about a flamebait rant, commented on by trolls.

God bless Slashdot.

Re:Casting

[Dutch Gun]

Modern, properly designed C++ code is absolutely safer than C code. However, because C++ is a superset of C, you can obviously write code that's just as unsafe as C, simply by ignoring the best practices and writing "C with classes" (which many do). A lot of what you can do in C++ exists solely to provide backward compatibility, both with earlier versions of itself as well as with C.

C++ gives you the ability to create new types using objects, which you can operate on both through member functions as well as logical operator overloading (where it makes sense to do so). For instance, you could create a class for handling file paths (as opposed to using raw character pointers or arrays, or even C++ strings), and when that class is properly developed and debugged, you can then be confident that you no longer have to worry about accidentally creating a security vulnerability or introducing a crashing bug. Moreover, it can handle path-specific things, such as ensuring proper form when paths are concatenated. Even better, when compiled down, it's really no different than code written in C, since C++ still adheres to the "zero-overhead" principle for most features.

When people talk about C++'s "dangerous casts", they're almost universally taking about "C-style casts", which are discouraged in modern C++. Instead, you should use the more explicit casts, which either use static compile-time checking or even run-time checking as appropriate. Whenever you have to resort to a C-style cast in C++, you had better have a *very* good reasons (in many cases it's just a design failure). Nowadays, that also includes managing raw memory or raw pointers thanks to the addition of standardized smart pointers.

This is why C++ is almost universally used in the videogame industry (I work as a videogame programmer), because is strikes a reasonable balance between safety, advanced language features, and performance. It's also nicely compatible with C libraries, with which we often have to interface at the OS level, or when using 3rd party libraries. And finally, while "better" alternatives arguably do exist, C++ is also well supported and extremely ubiquitous across the industry. As the saying goes, "quantity can have a quality all it's own". This is important when trying to hire experienced developers, or looking on the web for solutions to a problem.