
I disagree with Linus Torvalds about C++ (2009) - piyush_soni
https://www.johndcook.com/blog/2009/09/15/linus-torvalds-cpp/
======
sytelus
I've been trying to recruit good Modern C++ devs for almost a year and it's
_very very_ difficult. Even people with significant experience in their
resumes usually fail to answer most basic questions like what is RAII or const
correctness? In what cases would you rather pass around naked pointers instead
of smart pointers? And so on. I shudder at the thought of these people writing
C++ code and putting it in production. In C++ there are only few ways to do
things right and _lots_ of way to do it wrong. There is a gotcha virtually in
every turn of the language, often not caught by compilers even with all
warnings enabled. To top this off, static analysis and linters remains
extremely poor for C++.

I understand Linus's argument that in large collaborative C++ projects driven
by volunteers, you can easily end up with messed up code base littered with
stupid mistakes. C is slightly easier to understand and deal with -
relatively. Also note even fewer people actually knows what C++ features you
can use it on bare metal or kernel code.

On a fun side story, Windows NT team initially had huge debates on using C++.
Dave Cutler was firmly against using C++ to build OS if I remember correctly
but the graphics group decided to be hip and modern and do everything in C++.
After long delays and frustration graphics group had to revert to C.

~~~
stochastic_monk
I feel that I’m more skilled in C++ because I developed a large project in C
first. Whether or not C is the language one ultimately chooses, it makes one
aware of the tradeoffs and benefits of various coding styles.

~~~
sytelus
Main advantage of C is that it forces you to understand what goes on under the
hood. To many C++ programmers who didn't do much work in C, if you ask how the
variable var1 bellow gets allocated, they will be scratching their heads. As a
former C programmer, this is the first thing I try to understand - who is
allocating what and who will be freeing it up and how. I don't like anything
to be black box or performing magic for me. But many quick short and sweet
courses on C++ completely skip this. There is in fact a book someone showed me
which said that you don't need to worry about memory allocations in modern
C++, just use smart pointers and everything will be taken care for them! Poor
souls!!

    
    
      void f() {
        Vector<int> var1;
      }

~~~
0xcafecafe
Any C++ programmer worth their salt should know that a vector is implemented
using begin and end pointers. I believe its do with the person than the
language. The same person can miss nuances of C as well.

~~~
gpderetta
Ahem... I think that the tipical implementation is a triplet of base pointer,
allocated size, initialized size.

~~~
stochastic_monk
I expected it would be, and that’s how I’ve implemented my vector variants,
but I checked the source code for libc++ and libstdc++. Both use two pointers.

~~~
gpderetta
Interesting. I do remember inspecting _M_begin and end in the debugger.

I can't be bothered to check the implementation now, but the allocated size
must be stored somewhere. My first thought of inferring the capacity as the
smallest power of two greater than the used size doesn't work as the vector
size can shrink without affecting capacity.

~~~
stochastic_monk
The used size is end - begin; the capacity is stored in addition. That’s why
sizeof(std::vector<T>) is 24 on x86-64.

------
jcelerier
let's keep in mind that even though Torvalds said this from the kernel point-
of-view, he agreed in porting his userspace app Subsurface from C with GTK to
C++ with Qt.

[https://liveblue.wordpress.com/2013/11/28/subsurface-
switche...](https://liveblue.wordpress.com/2013/11/28/subsurface-switches-to-
qt/)

Besides, there's really not much point in comparing, 1991 non-standardized
"vector<bool> sounds like an awesome idea but first we have to find a compiler
which implements inheritance properly" C++ with 2018 "you can compile template
metaprogramming and constexpr stuff on commodore 64 and windows 10 and it
works fine"
([https://www.youtube.com/watch?v=zBkNBP00wJE](https://www.youtube.com/watch?v=zBkNBP00wJE))

~~~
Taniwha
exactly - it's that "system level" kernel point of view that's important - I
write a lot of embedded/real time/kernel code and essentially the thing you
have to avoid is "new" which is sort of the heart of the language ....

Why new? because you don't have a heap in the kernel, or practically on a
system with 20k or ram, new is also bad in real time code because underneath
it is malloc and (like printf/stdio) all the mutexes that protect code that is
messing with the heap structure .... and that way lies priority inversions and
heisenbugs and other dark beasties ...

(for a lot of real time code new is great at the beginning of time, but not on
the fly while the world is running)

~~~
atilaneves
You can overload operator new to not use the heap. You can use allocators.

~~~
heavenlyblue
Overloading new (for the purpose, of e.g. adding a thread-local allocator)
adds implicit global state that isn't always easy to manage.

~~~
gpderetta
Sure, but no more than the standard allocator. Explicit allocator objects are
a superior solution most of the time anyway.

------
jstimpfle
> For example, once you’ve allocated and de-allocated C structs a few times,
> you realize it would be good to have functions to do this allocation and de-
> allocation. You basically end up re-inventing C++ constructors and
> destructors.

Conflation of resource allocation on the one hand and construction (a.k.a.
initialization) on the other.

Good C programmers do not re-invent C++ constructors and destructors, because
they don't think what C++ constructors do is a good idea to do.

While C++ allows to separate allocation and initialization ("placement new")
that goes against the grain of the language and its ecosystem. You're still
left with constructors new-ing nested things themselves, and you're still left
with exceptions from constructors while a simple return value would be better.

> A typical C or C++ programmer simply will not write anything more efficient
> or more robust than the methods in these libraries if they decide to roll
> their own.

A typical C programmer will write something _different_ in the first place.
Something that doesn't take ages to compile. Something that doesn't do
allocations behind their back. Something that doesn't spew out nigh unreadable
error messages if they got a simple thing wrong. Something that doesn't
encourage clever code that isn't doing anything useful. Something that doesn't
require loads of boilerplate and duplication (thinking of const for example)
for the simplest task.

~~~
zozbot123
> Conflation of resource allocation on the one hand and initialization (a.k.a.
> initialization) on the other.

a.k.a. RAII (Resource Allocation Is Initialization). Which is very often what
you want anyway.

~~~
bunderbunder
As others have said, it depends on your context. If you need to be able to
maintain tight control over resource usage, for example, RAII creates
challenges. It can also be a bit of a chore to think about if you're doing
interop with other languages.

I've come to think of C++ as the tiktaalik of programming languages: It can
live in two environments, and was an important evolutionary step in
transitioning from one to the other. But, ultimately, it embodied so many
design compromises that it was never going to be ideally suited to either of
them.

------
bborud
I can understand where Linus is coming from. C++ does indeed have STL and
Boost into which much thought has gone. But they do not feel like an integral
part of the language or a natural extension of it. The verbose, sometimes
awkwardly complex syntax that results is also a problem. It may work for those
who can stand this. But for others it is not so pleasant.

When using C++ I feel like too much of my time is spent having to understand
how the abstractions work under the covers. I feel that this is somewhat
pointless. Shouldn't a high level language free you from worrying about the
details?

~~~
leetcrew
c++ is only a "high-level language" in comparison to c or asm. it should
basically never be your first choice for a crud app in 2018. the point of the
standard library is not to give you a bunch of abstract containers that "just
work", but rather to give you many highly-optimized implementations of
specific data structures to choose from.

~~~
bborud
> the point of the standard library is not to give you a > bunch of abstract
> containers that "just work", but rather > to give you many highly-optimized
> implementations of > specific data structures to choose from.

Are you talking about C++ or high level languages in general?

Either way you can come at this from multiple directions. For instance I like
the way Josh Bloch designed the collection classes of Java, where you have
some key types (given as interfaces) and multiple implementations as well as
adapters. The focus is on the semantics and not really the implementation. For
the most part you try to write code so it can take advantage of as many
implementations of the same type as possible.

Rather than focus on implementation detail I think a standard library has two
jobs: the first is to serve as an example of idiomatic language use. The
second is to make the language useful - meaning that it should be possible to
do practical things with only the standard library. Today such a practical
thing might be to perform an HTTP request without having to go on an easter
egg hunt.

I think one reason Go is becoming so popular is that it isn't obsessed with
"purity". Remember Scheme? Remember how useless it was out of the box? It
couldn't actually _do_ anything.

~~~
leetcrew
> Are you talking about C++ or high level languages in general?

c++ specifically. if I don't care about the difference between, for example, a
list, a vector, and a deque, I am probably going to choose a higher level
language to work in. that said, you can write container agnostic code with
templates and range-based for and/or iterators if you really want.

I agree with your other points. in particular, it's annoying to have to reach
for libcurl every time I want to do simple http stuff, and I have fond
memories of scheme from cs 101, as beautiful and unpractical as it is.

~~~
bborud
> that said, you can write container agnostic code with templates and range-
> based for and/or iterators if you really want.

You can, but people don't often do.

------
xvilka
It worth noting that C++ changed a lot since 2009 and many scary things were
deprecated. So far biggest problem is amount of legacy-written code at this
point. Though in my opinion languages like Rust fit better than C++ or even C
for writing kernels and runtimes.

------
frou_dh
Ancient flamewar topics are insanely boring

~~~
jacquesm
Agreed, unless the purpose is to extract lessons learned. I can think of
several where that has not happened yet.

~~~
giancarlostoro
One thing I always do when they happen is read through the comments anyway,
sometimes people bring up some rather insightful things about a language,
editor or whatever. Having heard from an emacs user why he prefers it over vim
made me really appreciate emacs. I'll use either vim or emacs though, just
don't care personally as long as I can: open a file, edit a file, and save a
file. I also use full blown "bloated" IDEs.

Of course I ignore a lot of comments, but try to go for the ones that seems
intelligible.

~~~
cube2222
What was it that he said about emacs?

~~~
giancarlostoro
It was some blogpost I can't seem to find, but they explained all the
different things they can do from within emacs, which were lots of things vim
doesn't seem to be capable of doing, things such as SSH'ing to a remote system
to open files remotely, fully being capable of handling mail through emacs,
being able to use emacs as a web browser as well which is interesting, and
other things which were fascinating enough to me. There's also the built-in
git functionality, which some people use emacs exclusively to manage their
usage of git.

The emacs editor really is an Operating System to it's own extent. I really
fell in love with the idea of being able to just work all day with nothing but
emacs, I have not gotten to that point yet though. Being able to not leave my
editor for anything sounds pretty useful if done right.

------
Const-me
> a lot of substandard programmers use it

That’s no longer the case. Substandard programmers have moved towards safer GC
languages.

> STL and Boost and other total and utter crap

For many parts, yes indeed, but both are optional. Boost is not even a
standard library.

> typical C or C++ programmer simply will not write anything more efficient or
> more robust than the methods in these libraries if they decide to roll their
> own.

Some parts of the STL are just horrible. Look at <iostream> header. Even with
my experience, I will struggle trying to roll my own IO that’s less efficient
or less robust, I don’t think it’s humanly possible.

Other parts work OK but just too slow. For example, I avoid using standard
collections except strings and vectors: [https://github.com/Const-
me/CollectionMicrobench](https://github.com/Const-me/CollectionMicrobench)

> to limit yourself to all the things that are basically available in C.

C++ has a problem, it doesn’t have an ABI. When you’re writing complex enough
systems with it, you either invent one on top of it (see how MS did it in
Windows with COM, IUnknown + HRESULT, used in DirectX, Media Foundation, .NET,
UWP, and many other libraries & frameworks), or indeed limit yourself to
things available in C, plus just a couple extra like unique_ptr, string and
vector.

However, on the lower level, in the implementation of these components, C++
helps a lot. If you’ll look at how MS implemented C runtime library routines
like printf(), you’ll find they have used a lot of C++ inside, even templates
to avoid code duplication caused by char/wchar_t versions.

------
seba_dos1
If your argument for STL/Boost is "A typical C or C++ programmer simply will
not write anything more efficient or more robust than the methods in these
libraries if they decide to roll their own", it's a sign you might be missing
the point :P

------
billfruit
Linus may be fine with C, but I do find that using C for larger projects is
cumbersome for its lack of quality-of-life features. Making ADTs with C is a
pain, because you can't define a type and keep creating object instances of
it. Lack of namespaces makes naming things convoluted. Exception handling is
non-existent. The type system is a joke, C functions happily take arguments of
wrong type at compile time and then segfault at run time. Lack of array bounds
checking places greater demands on the programmer. Too much abuse of the bare
bones pre-processor macros. Multidimensional arrays are very complex to use.

------
Koshkin
C++ fell victim of the incremental approach to building a language. There
never was a big picture. Ten years after the language had been conceived it
was realized that it was STL that gave C++ its life the true meaning. C++ is
the result of a very logical evolution (of C), which makes it, contrary to the
popular thinking, very difficult to argue against its features on purely
logical grounds. And the evolutionary road it travels is all paved with good
intentions. But we all know where such road leads, and I would prefer an
intelligent design in the first place.

------
dathinab
Wenn speaking with some people experienced in C++ I often got feedback along
the line of: " For a good C++ programmer C++ is as good as any other language,
no maybe even better ... it's just that good C++ programmers are so rare that
they are irrelevant for any company."

Or with other words: While there are many reasonable good C++ programmers
there are view which are really good due to the complexity of C++.

------
garryterm
Trovalds is not comparing top C programmers to average C++ programmers. What
he meant was -- a lot of people mess up with kernel code and some of them
choose to contribute back. Most of these guys must be => average programmer.
So if these guys used C++ to give back to the kernel then it would be chaos.

~~~
Koshkin
Wasn't BeOS written in C++? I've heard people were impressed by the quality of
its code.

~~~
waddlesplash
The userspace was, the kernel was not. Haiku's kernel is almost entirely C++,
though, and people are usually very impressed by our code quality :)

------
objektif
I am not a great developer by any means but how can anyone claim that syntax-
wise C++ is a good language?

------
xte
While I'm nowhere near as talented a programmer as both Torvalds and Cook I
disagree, perhaps with both.

We have tons of crap anywhere due to bad code monkeys, kernel included, and
these days with actual computing power keep using low level languages is a
nonsense.

I'm not a fun of Go nor Rust and I can't say how hard can be write a modern
kernel in a functional language like a Lisp or Haskell (thou in the past we
have had LispM) however IMO we need to use high-level language to develop the
same thing with less complexity and much more readability. Sooner or later any
complex project will became so complex that even in FOSS world nobody can
really know it enough to master it's evolution.

~~~
jacquesm
The problem is that such a high level language hides the complexity, making it
much harder to reason about subtle side effects.

~~~
xte
Ancient Alto workstations or LispM are build around high level languages and
they were FAR superior to any contemporary competitor... So technically IMO
that's not a real arguments. Maybe a cost arguments but that's a really
complex point to evaluate.

------
phkahler
>> Well, I’m nowhere near as talented a programmer as Linus Torvalds, but I
totally disagree with him.

I think that says it all. On top of that, Linus is in charge of the project he
works on and is allowed to run it as he sees fit. Given all that, I decided to
stop reading. OK, that and I already have my own impression of C++ but this
intro doesn't make me want to reconsider.

~~~
ptx
> On top of that, Linus is in charge of the project he works on and is allowed
> to run it as he sees fit.

The argument is not about whether Linus should be forced at gunpoint to adopt
C++; it's about whether adopting C++ would be a good idea.

Deciding if something is good or bad is separate from deciding if it should be
done or not. Nobody will stop you from e.g. putting pants on your head if
that's what you really want, but we can have a discussion weighing the pros
and cons of doing so, after which you can make a more informed decision if you
choose (or not!) to listen to the feedback.

