

A response to Linus Torvalds on C++ (2007) - geekam
http://warp.povusers.org/OpenLetters/ResponseToTorvalds.html

======
jnazario
i had been a C++ hater for a long time, partly because of the environment i
was in (strongly C, anti-C++) and partly because most of the C++ hackers i
knew enjoyed abusing language features.

i'm reading a bunch of C++ lately and i have to say i like it, i like it a
lot. it's something i may have to dive into and actually learn.

some of this is due, i think, to solid standards coming in, but also a lot of
growth on my part as a coder.

plenty of things are done better in OOP than not, where re-use through
inheritance, design by composition, and modularity are needed and well
executed.

my bigotry against C++ has ended.

~~~
pavanky
_"I like your C++. I do not like your C++ programmers" -- Gandhi._

While I am at it, it is my opinion that bad C++ programming style is much
worse than bad C programming styles.

For example <http://i.imgur.com/xtohcJH.jpg> CUDA programmers would
understand.

~~~
thepicard
Aren't namespaces a C++ feature?

~~~
adamnemecek
I assumed that he switched C and C++ in that sentence.

------
grogers
Ah this old chestnut... Clearly the author believes in fighting flames with a
flamethrower. Anyone could write the exact same arguments against this piece,
just as he does against Linus. His arguments aren't well backed, and his tone
is even more inflammatory than Linus...

Sad to say that a lot of people's bias against c++ is rooted in their
experience with it 10-20 years ago. Poor compilers, poor stdlibs, poor
portability, etc. If that is you, I would encourage you to check out what
modern c++ is like. C++11 fixes a bunch of things, c++14 will fix some things
that the committee missed. Yeah, c++ is big and complicated, but so is every
language, even C. Yeah the C core language is small, but any large project
starts either rolling their own library for data structures, algorithms,
string processing, etc, or linking in behemoths like glib. C++ just comes with
a lot of the basics included, and learning the best practices and modern
idioms of using the language isn't that bad. Consider:

    
    
      unique_ptr<foo> bar(); // c++  
      foo* bar(); // c. 
    

The C++ version conveys way more information (and is almost impossible to
screw up its use accidentally), without the need for comments, and compiles to
the same code. This is just one example, but they abound.

------
rikkus
I've written a _lot_ of C++. I'd rather not go back to using it, if possible.

Recently I found this: <http://yosefk.com/c++fqa/>

It explains most of the reasons I disliked C++ and, if you've ever used it,
you might recognise the issues dealt with.

~~~
Dylan16807
Can you be more specific, or link to some parts that show C++ problems? I
clicked on a random heading and got an explanation of how 'inline' is a
complex issue, and that's in both C and C++. So it's certainly not the whole
FQA.

------
smegel
What a bad article. Instead of discussing the big ideas in depth it first
starts with a caricature of what is referred to as a "C-hacker"...then delves
into an logical analysis of Linus' sentence structure including the
implication of his use of a comma.

It looks and feels exactly like the kind of defensive article you would expect
from a insecure C++ programmer. Maybe he should have just tweeted "Everything
Linus said is wrong! WRONG!" instead.

------
EternalFury
Originally, I disliked C++ because it was poorly supported across platforms.
You had this level of standard support on one platform, but only that level of
standard support on that other platform. From STL to every other useful
library. It made things difficult to port. But that was long ago, before I
stopped using C++. Things may have changed since then. Platforms have become
fewer and far in between at least. C is widely implemented on all platforms
and in fact, most platforms have large chunks implemented in C.

The other thing is about class-based languages. They are great for
implementing _hierarchies_ of concepts, like GUI toolkits and a few other
things. But, they do promote bulk and it's not rare to have a lot of object
thrashing. That's not specific to C++, though.

Third, system-level library are often exclusively exposed via C libraries.
Core things like BSD sockets, POSIX threads, memory management. Yes, you can
wrap them in C++ or use C++-based libraries that add sugar on top, but more
often than not you end up wondering "why don't I use the system APIs
directly?" You often feel like you have to jump through unnecessary hoops when
you don't.

Just my opinion, of course. I would use C++ if there was a good reason for any
particular job. It is just not my natural inclination.

------
robot314
First off, with regards to calling strlen multiple times in the loop, the
author is just plain wrong. Gnu C has something called __builtin_strlen which
is a compiler extension that can replace the function calling a statically
allocated string with just its length[1] making it essentially zero overhead.
Second, strlen is defined with __attribute_pure__, which means that the
compiler can optimize to just one function call in all other cases[2]. With
these two compiler optimizations, C is at least as efficient as C++ in worst
cases, and much better otherwise.

[1] <http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html> [2]
<http://ohse.de/uwe/articles/gcc-attributes.html#func-pure>

~~~
jhasse
But what "if the doSomethingWith function takes a non-const pointer"?

Also why would C be better otherwise?

------
kyllo
C++ is painful, but language wars are more painful and divisive in the long
run. This is from six years ago, why bring it back from the dead? C vs. C++
squabbling should have ended in the 90s IMO.

------
nirai
Turns out it is also quite easy to generate total and utter crap by writing
about C++.

It is reasonable to speculate that C++ is more popular with beginner
programmers than C, and that this may significantly affect the characteristics
of a software project developed by a big team or community, as opposed a
single particular programmer.

It is also reasonable to assume that trovalds speaks out of his experience and
doesn't merely speculate.

As for me, his observation perfectly matches my personal experience.

------
icebraining
I don't see what's so extraordinary about Linus' claims that bad programmers
make the language worse and easier to produce crap with.

I think it's clear that Linus isn't talking about the language as the syntax
and semantics that get accepted by a compiler, but in a broader sense,
relevant to the Real World, which includes a social context.

There's a culture and social context around a language, that includes things
such as idioms, best practices, libraries, learning material, etc, which are
fundamental to the practice of programming in it.

------
McUsr
I don't code a line of C++ if I don't have to.

Apple uses C++ in their kernel in a nice way, they don't use virtual methods
and templates.

I agree totally that C++ looks good and all, and that there might be bright
sides to it. But to me, it is not as discernible as C at least. And I do enjoy
programming in C, I need to feel I am in control, and C gives me that.

------
icebraining
The author seems to assume that Linus is against objects. I think this makes
it pretty clear: <https://lwn.net/Articles/444910/>

------
MostAwesomeDude
This article cherry-picks and attempts to bang on the table, probably because
banging on the facts would not turn out so well.

He claims that C was designed by committee, which I can only assume is a
defensive projection meant to hide that C++ was designed and is maintained by
committee. He points out mplayer as an example of C code that is supposed to
be good but is actually bad, which is a low blow. (mplayer's code quality has
always been awful and this is well-known in the community.)

The railing against C++ object models being bad is similarly defensive, and I
get the feeling that the author is deliberately trying to make people forget
that pImpls ever happen.

C++ is an _incredibly_ obtuse language, full of so many misfeatures and fancy
whirligigs that it's difficult to be certain that even repeated reads through
a file are giving you the correct impression of structure and flow.

