
The Design of C++ (1994) [video] - pjmlp
http://www.computerhistory.org/collections/catalog/102624733
======
Koshkin
The language may seem complex to some, but so does math. It is the single most
powerful programming tool the world has ever known. Sure, it may be hard to
see that it is beautiful, but that is so only because it is a product of both
intelligent design and evolution. The language structure is extremely logical,
and there is very little that could be changed in it without the danger of
destroying its finely tuned fabric built from intricately interacting concepts
and mechanisms. In that, it is radically different from the multitude of
"pure" programming languages, some also of a respectable age, and it is
because of that, unlike those languages, it became, and has been for over a
quarter of century, the single most important programming language. Some may
say: yes, clearly, this language is borne from good intentions, but are not
these the good intentions that pave the road to hell? To that I have only one
thing to say: this is where you go looking for good company :)

~~~
KKKKkkkk1
Let's bring up some technical details to see whether there is a deliberate
thought process behind the evolution of C++. Recent versions of C++ have the
auto keyword. It's a cool new feature grafted onto C++ from other languages
and meant to make the programmer's life easier. It lets you avoid typing
things like

    
    
      for (std::vector<std::pair<int, double>>::const_iterator it = v.begin(); it != v.end(); ++it) {
        foo(*it);
      }
    

The above used to be the recommended way to write a loop until C++11, and was
supposedly superior to

    
    
      for (int i = 0; i < v.size(); ++i) {
        foo(v[i]);
      }
    

which was considered to be error prone and unsafe. But now things are much
nicer and you can write

    
    
      for (auto x : v) {
        foo(x);
      }
    

Looks so much better. Clearly "auto" is a win for C++ programmers. But wait,
it turns out that there's actually a bunch of different ways of writing the
auto keyword that have subtly different semantics. You can write "auto", but
you can also use every possible combination of "auto" with "const", "&" and
"&&". So things like "auto&&" or "const auto&" are also perfectly valid and
sometimes preferable to simple old "auto".

Let's put aside the fact that you can't explain the difference between "*",
"&" and "&&" to a C programmer without them bursting out laughing. Why does
auto have six different variants? Isn't this emblematic of how C++ is
evolving?

~~~
dTal
As a light C programmer, no part of this post does not make me WTF hard. Would
I actually be expected to type that cataclysm at the top? What's wrong with
the C-style loop? Was 'auto' the best name they could come up with for this
feature?

~~~
hawski
They have chosen auto, because it was already a reserved keyword, but it was
practically useless.

------
hga
Even if you dislike C++, or like me, came to loathe it, I _highly_ recommend
the book he published in the same year, _The Design and Evolution of C++_
([https://www.amazon.com/Design-Evolution-C-Bjarne-
Stroustrup/...](https://www.amazon.com/Design-Evolution-C-Bjarne-
Stroustrup/dp/0201543303)). It's very educational about you go about making a
successful language in an existing ecosystem, and even after swearing off the
language I don't regret one bit the time I spent reading the book.

~~~
byuu
After seeing P0145R3 on C++17 refinements to expression order guarantees (and
many things like that before it) ... I think I've finally started to actively
dislike C++ now as well, after nearly 20 years of using it daily.

They had a golden opportunity to fix it, but even with C++17 and the
expression "a(b(), c());", it is _still_ left indeterminate whether b() or c()
will be invoked first. Even between calls in the same program! So what if they
have side effects? It might be a picosecond faster if the compiler can run c()
first to push its argument onto the stack first!

I'm all for the power for C and C++ to optimize to such efficient code, and
not consume many resources. But we're a long ways from the PDP-11 days and
processor frequencies measured in KHz, and compiler developers are living in
some alternate reality where the only thing that matters are benchmarks, and
they'll happily undermine the stability and security of our software by doing
things like erasing that call to memset() that cleared your private key from
memory; or remove that conditional expression entirely because it detected the
_possibility_ of an integer overflow, so that means it can do whatever it
wants! ... even though the world has been twos-complement for decades now.

Given the very real security concerns and exploits we keep seeing in code ...
I don't believe that using languages full of undefined/unspecified behavior is
the way to build stable and reliable systems.

Nobody can keep track of the hundreds of UB cases in C/C++. We all do it, and
then suddenly a new GCC comes out with a new benchmark optimization, and now
our programs are misbehaving.

I'm willing to pay a 5-10% penalty, and give up compatibility with the
Motorola 68000 platform, to get well-defined and predictable behavior. Maybe
you keep C/C++ for that gaming OS, or that Wall Street trading system. But on
my server? I can spare the CPU cycles.

And yet, everything is built on C/C++. Your OS? That Python interpreter? Your
web browser's Javascript engine? The .NET runtime? All C/C++ under the hood.
We're building on quicksand; when we need a solid foundation.

~~~
netheril96
The standards body move very slowly. More practical approach is to push
compilers to add more options to define undefined behavior so that we have
safety with the minor cost of performance. We already have -fwrapv, -ftrapv
and -fno-strict-aliasing. We could ask for more and a general -fsafe flag.

~~~
pjmlp
> We already have -fwrapv, -ftrapv and -fno-strict-aliasing.

You have it in specific compilers, not in the standard.

Not everyone is able to go installing clang and gcc on their work platform,
when there are so many compilers to choose from.

[https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_comp...](https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_compilers)

------
mannykannot
I finally figured how Dr. Stroustrup can always make C++ seem like not only a
reasonable thing, but probably the best possible one. He has chosen a number
of goals that, while being reasonable and desirable individually, each tend to
complicate the realization of all the others. Consequently, for any of the
complications of the language, he can pick a couple of goals and show that
they make the complication unavoidable.

~~~
jnordwick
We will now call this "Stroustrupping": choosing a large number of
incompatible goals and using a subset to defend any argument while ignoring
the fact this subset conflicts with many of the other goals, such as the
subset used to defend the previous argument.

~~~
mannykannot
To be clear, I am not suggesting that Stroustrup is being misleading in any
way. I think the complexity is inevitable, given the goals, and I came to this
view from asking whether there is one thing about C++ that leads to this
complexity. Perhaps the closest thing to a single cause was the decision to
make C++ a superset of C, which in turn leads to the use of naked pointers,
arrays that do not know their dimensions, and to accessing arrays through
pointers. Another issue may be separate compilation, which seems to complicate
templates and polymorphism.

------
kaspm
I believe it's spelled "Stroustrup"

~~~
JohnStrange
Makes you wonder whether it's possible to infer the characteristics of a
programming language from the name of its main inventor, doesn't it?

------
e534808d56
A nice "interview" with Bjarne from the yealy revue on the center of computer
scince on the university of copenhagen:
[https://youtu.be/TTVCaZVUvC0?t=156](https://youtu.be/TTVCaZVUvC0?t=156)

