Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf] | Hacker News Reader

Evolving a language in and for the real world: C++ 1991-2006 (2007) [pdf]

stroustrup.com

48 pointsotoolep25 comments

Another good read is the book "The Design and Evolution of C++".

http://www.stroustrup.com/dne.html

It does provide a very clear rationale why C++ became the way it was (C++98), given the design goals and the constraint of being C compatible as much as possible, both in language and compiler toolchains.

It was also a fantastic way to learn the language.

Going through all the design decisions, the underlying implementation, the trade offs helped me build a mental model that massively increased my productivity and intellectual happiness.

I yearn for similar works for other languages (e.g., clojure).

I am aware at least for Ada,

http://www.adaic.org/ada-resources/standards/ada83/

Smalltalk (green book),

http://stephane.ducasse.free.fr/FreeBooks/BitsOfHistory/

Cedar,

http://bitsavers.trailing-edge.com/pdf/xerox/parc/techReport...

"The Ruby Programming Language" by Flanagan and Matsumoto may not have that as it's main goal, but gives a very good overview on why features are how they are and even gives some advice from the creator of the language himself and some commentary on them (e.g. flip-flops are considered an implementation oddity kept around for backwards compat).

http://www.amazon.com/Ruby-Programming-Language-David-Flanag...

I think it's the most relevant Ruby book, because it documents the basic thinking and mental approach of the language, which is actually very stable.

This is a great paper! It was given at HOPL 3 (History of Programming Languages, a conference which runs every 15 years). I'd recommend all of the HOPL 3 papers to aspiring language nerds, but especially the ones on C++, Lua, Haskell and Self.

Yeah, for a somewhat longer paper, it's eminently readable. Very human in tone.

It's Bjarne's style - long but readable texts.

The chapters C/C++ Compatibility (7.6), Sun and Java (7.7), Microsoft and dotNet (7.8) and Retrospective (9) were very informative. It's a history lesson every programmer should read.

"It is more important to allow a useful feature than to prevent every misuse."

That's from his "Design Support Rules" section early on in the paper. I am still going through the paper, but this seems like a good rule and a reason why pointers are still allowed despite the protestations of people who hate C++. Sure, you can get into a pickle with them but that's not the language's fault.

Of course, there has been the rule "use references where you can, pointers where only absolutely necessary" but it's a difficult habit to break...

Two that jumped out at me: "C++'s evolution must be driven by real problems" and "Don't get involved in a sterile quest for perfection."

Arguably, that philosophy is why C++ went on to rule the world, and Lisp and Haskell remain niche languages.

Interesting tat Go has the same philosophy yet is anti-C++ many ways.

The difference is that Go doesn't believe "useful" is enough justification-- usefulness is balanced against clutter and complexity.

Go has a different perspective on the cost of clutter and complexity - how much it costs in terms of compile time when you maintain a million line code base over two decades. Going from a 45 minute compile to a 10 second compile adds up over a couple decades.

But it is still the same philosophy - Go's design is being driven by real problems that people ran into.

"Exceptions are typically — and correctly — seen as a control structure". So much for those who say using exceptions for flow control is bad.

Goto is a control structure as well. Does not mean you should use it (with certain exceptions). Unlike exceptions though, you can use it in limited amount in your codebase. With exceptions it's either everywhere or nowhere.

If they're important enough to be part of the language, somebody's going to use them... and common library functions will too. Exceptions aren't usually something you can boycott in a language ... and if you're going to have to use them, well, it's best to treat them as part of your program's logic, yes? Consider the many different errors Google handles and it's not always a dead failure... https://github.com/google/lmctfy/blob/master/util/task/codes... it's nice to be able to both return a value and an unambiguous exception state with automatic closure of resources (e.g. finally, or rewinding the stack...) such that you can safely retry without cleaning up after yourself. That's the goal here. Of course, Google's Go language avoids exceptions by using multiple return values, conventions and a defer statement... but then you can't easily put all your error handling code in any one place, can you, without restructuring your code? To each language its conventions, I suppose.

Yeah, I'm just going to go ahead and disagree anyway. Not only are they a poor structure for flow control they are an inefficient and slow one too, as Andrei mentions in his 2012 talk on expected<T>, a talk which also nicely illustrates the shortcomings of using them for their intended purpose as error handling.

In fact exceptions as implemented in C++ has to be one of my last favourite things about the language. They are an all or nothing proposition and yet were put in half heated and unchecked. Many years later the result I see is some or most programs have a catch(...) at some high level. Something went wrong, who knows what, can't even set the debugger to break at exceptions because they're being thrown everywhere all the time for flow control.

> ...can't even set the debugger to break at exceptions because they're being thrown everywhere all the time for flow control.

Any C++ debugger worth using will allow you to break on certain exceptions and ignore others. Even gdb permits this: http://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.htm... Any decently designed C++ program will have a sane set of exception classes that will be easy to filter when debugging.

The heuristic is that if the case is more frequent than something like 1/1000 then you don't use exceptions in these languages (C++, Java, ...). As they are a lot cheaper in languages like ML, people there tend to use them more for early exits out of things like folds.

A simple example:

  let prod = List.fold_left (fun acc a -> acc * a) 1.0 xs

should not fold over the whole list if a factor is 0.0 so they tend to use exceptions for that (or delimited continuations)

Java doesn't really give you a choice though, because so many of the standard library classes have exceptions baked in. Any code you write related to file I/O for example will have to have either a "throws" or a "try/catch" on it, or else it won't even compile.

Checked exceptions are much closer to "error codes" than unchecked exceptions. Checked exceptions just loosen the constraint a bit and let you defer handling to anywhere the caller's remaining function scope (or explicitly continue the throw)

C++ exceptions came from ML.

The original purpose in ML was definitely control flow. Or rather, controllable heuristic search in the context of a proof assistant. A heuristic could "give up" by raising an exception and a meta heuristic would then try something else or give up.

They worked well because memory handling is clean and automatic in ML and because proof assistants mainly work in their own little world with little to no I/O (apart from logging to a file/stdout/stderr).

Without meaning any disrespect, this is a sort of naive perspective that comes about when you consider a language in isolation.

When you try to use exceptions, you'll quickly encounter the following:

1. Your C++ code may be called by C code that knows nothing of exceptions.

2. Exceptions have big implications for API design. See for example GOTW #8 http://www.gotw.ca/gotw/008.htm , which acknowledges that "some interfaces can't be implemented in an exception-safe manner."

3. try/catch/throw have performance impact. Compilers optimize for the no-exceptions-thrown case, and the practical cost of throwing an exception can be prohibitively high. Google "Zero-cost Exception" for more.

The net result is that proper exception handling is difficult to incorporate gracefully, and "exceptions are all fatal errors" is a very reasonable position. Last I checked, Firefox is compiled with -fno-exceptions, and this is how Cocoa frameworks work as well.

Won't be the first time that I think Stroustrup has made a serious error, and is compounding his error by not repudiating the feature.

Go read Sutter's _Exceptional C++_ or any of its follow-on books. It appears nearly impossible to write solid software when you allow exceptions into your set of control structures.

The best response to an exception is: Restart. Catch the exception in something like main(), take a dump or write some diagnostics, and restart your app. You'll have a system that is more reliable and of better quality than if you try to handle exceptions "correctly" in the face of non-exception-neutral code, 3rd party libraries that get things wrong, and your own bugs, which are going to be many, and deep, and subtle, and probably intractable.

C++ is used in many environments where "restart" is not a viable option.

Straight from the man himself, Bjarne Stroustrup. Really interesting for any C++ programmer.

Reply on news.ycombinator.com