The Design of C++ (1994) [video]

http://www.computerhistory.org/collections/catalog/102624733

by pjmlp • 10 years ago

70 55 10 years ago

kaspm• 10 years ago

I believe it's spelled "Stroustrup"

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?

hga2• 10 years ago

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/...). 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.

lallysingh• 10 years ago

It's a solid book, but I wish there was something newer. It's 20 years old now!

npiazza83• 10 years ago

If America were a year it would be out for all of December.

profeta• 10 years ago

how can you loathe C++ without caming to loathe it? i mean, everyone is bound to hate it, but you have to try it first to be sure...

armitron• 10 years ago

How can you loathe Krokodil without coming to loathe it? You have to try it first to be sure...

clappski• 10 years ago

... I like it ...

hga2• 10 years ago

I think it's flaws, only somewhat addressed in recent revisions, are better known now than they were in the mid-'90s when I learned and started using it, plus the industry wide ... obsession? with OO and especially class based OO has subsided. So someone with good taste who reads and trusts what he reads of these details could, yeah, probably not legitimately loathe it, but at least decide without using it that it wasn't for him.

I changed the initial use of loathe in this context to dislike, thanks for pointing that out.

ArkyBeagle3• 10 years ago

Just don't assume loathing is linear...

ArkyBeagle3• 10 years ago

The sort of puppy-dog C++ style on Arduinos - a sort of pedomorphic variation on "'C' with classes", chock full of singletons and the inability of constructors to operate unless they're called in A Certain Place - pretty much works.

What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism.

santaclaus• 10 years ago

What's less attractive is Dogmatic Bikeshedding C++ OO Fundamentalism.

Is that a thing? I always saw more of that in the Java world than C++ -- Java's standard library is rife with the singleton factory decorator monstrosities that have come to be associated with OO, C++ and the standard library have always felt more generic-programy. Now egregious use of obscure template meta programming tricks because of perceived (vs measured) performance gains, I've seen some horrors there...

TickleSteve• 10 years ago

its actually the full gcc compiler on arduino.... not that they advertise that.

byuu6• 10 years ago

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• 10 years ago

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.

vvanders• 10 years ago

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.

Come over to the land of Rust, where you can keep your high performance memory semantics and safety :).

Seriously, life-long C++ dev here. Been writing C++ for almost 20 years now and I don't feel like there's anything I could do in C++ that I can't in Rust(both performance and functionality-wise).

yongjik2• 10 years ago

I'm not a big fan of UB either, but keeping the order of argument evaluation indeterminate seems very sensible to me.

Imagine you have a function like f(int, double). If argument evaluation order is fixed, you can no longer exchange the order of arguments: for all you know, someone might be depending on the first argument being evaluated first!

wildmusings2• 10 years ago

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.

If the order of b() and c() matter, then they shouldn't be in the same statement. That is an abomination. What you little you gain in terseness, you more than make up for in future headaches.

krylon• 10 years ago

I agree. I only spent very little time with C++, but that book was both highly interesting and very entertaining to read. Highly recommended!

e534808d56• 10 years ago

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

Koshkin• 10 years ago

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 :)

paulddraper2• 10 years ago

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

Really? Very little? Finely tuned fabric?

Is diamond inheritance really part of that fabric? And NULL?

C++ is old and has only accumulated, never lost. When I think "finely tuned fabric", I think of Rust, which has the fortune of decades of learning. C++ piled on rvalues and move semantics. Rust is the one that "tuned" its design.

I'm not dissing C++; it's a true veteran, and has witnessed entire languages rise and fall. But let's be honest: the design of C++ is (as one would expect for a decades-old language) organic, not "finely tuned".

shin_lao• 10 years ago

Is diamond inheritance really part of that fabric?

Diamond inheritance isn't a problem in C++ as each inheritance path is followed separately. A small price to pay to enjoy the power of multiple inheritance.

And NULL?

NULL is deprecated since C++ 11 in favor of nullptr.

C++ is old and has only accumulated, never lost.

You may want to have a look at the latest standards.

blub• 10 years ago

Rust isn't finely tuned either, it just has memory safety (finely) turned up to 11.

I wouldn't call C++'s design organic, just severly constrained by backwards compatibility. It is finely tuned, but the results are not even close to an ideal that didn't consider C. Finely tuned doesn't imply perfection.

stinos2• 10 years ago

I really like your description, it's pretty much the same as how I think about it. But only when I'm in a subjective 'C++ all the things' mood - which happens often, especially since C++14, there's just so much to love about C++.

When I try to be objective about it though, I'd say you are glorifying too much and skipping on the darker sides of it. You and me probably now exactly how to avoid those and that's also exactly one of the reasons why for us C++ is all utter greatness. But when I see inferior, dangerous, ugly, waiting-for-UB code produced by others I realize it's not all that great. Or maybe still great - after all you could blame their lack of knowledge instead of C++ - but I really wouldn't use terms like finely tuned or extremely logcical. Seriously, I've used the language for like 10 years and it still occurs to me that I see a C++ question and corresponding answer on SO which completely baffle me because I had no clue about that particular implementation detail. There aren't many languages like that. Here's one just from today: http://stackoverflow.com/questions/39422188/difference-betwe... granted I would never write that stuff, but also I really couldn't tell 100% sure how 'const int& x = 4;' at classlevel is supposed to behave.

pjmlp6• 10 years ago

That is my feeling when I look at enterprise C++ code, which usually never goes beyond "C with Classes" style regardless of the improvements the language has gotten over the years, which is why in the end I came to be an happy JVM/.NET camper that only uses C++ on side projects or when JVM/.NET projects need a bit of outside help.

cousin_it• 10 years ago

Hey, try compiling this:

    template<class T,class...>class C{C<T*const,T,C>a;C<T,C>b;};C<int>c;

KKKKkkkk1• 10 years ago

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?

pjmlp6• 10 years ago

At least C++ offers me tools to avoid leaking resources or corrupting memory, which cannot be said for C.

The fact that C11 made the security Annex optional, is a sign how much the C committee values writing safe code.

stinos2• 10 years ago

for (auto x : v) {

usually you'd use for(const auto& : v) though

dTal• 10 years ago

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?

mannykannot2• 10 years ago

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• 10 years ago

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.

mannykannot2• 10 years ago

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.

The Design of C++ (1994) [video]

Related Stories