Bjarne Stroustrup and C++

Zusammenfassung

Bjarne Stroustrup designed C++ as a practical tool, not a language research project. He wanted the simulation capabilities of Simula — classes, inheritance, type-safe polymorphism — combined with the performance and low-level control of C. He got what he designed. C++ became the dominant language of systems programming, game development, and performance-critical software for three decades, and remains one of the most widely used languages in the world. It also became, in the estimation of many programmers who used it, one of the most complex: a language where the same feature can be implemented five different ways, where undefined behavior lurks in code that looks correct, and where mastery takes years. Stroustrup designed C++ to give programmers powerful tools without forcing them to use them. Whether this was wisdom or permissiveness depends on which codebase you’ve worked in.

Cambridge and the Simula Encounter

Bjarne Stroustrup was born on December 30, 1950, in Aarhus, Denmark. He studied mathematics and computer science at Aarhus University (master’s degree 1975), then pursued a PhD at Cambridge, completing it in 1979 with a dissertation on distributed computing.

At Cambridge, Stroustrup programmed in Simula — the Norwegian language that had introduced classes and object-oriented concepts in 1967. Simula’s type system and class hierarchy made it significantly easier to structure large distributed programs than C or BCPL. Stroustrup valued this. He also found Simula unacceptably slow for systems work — its runtime environment added overhead that made it unsuitable for the performance-critical code he was writing.

He joined Bell Labs in 1979, where C and Unix were the native environment. His goal was to combine what he had valued in Simula with C’s performance and low-level capabilities — to create “C with Classes.”

C with Classes → C++

Stroustrup began adding class-based extensions to C in 1979. The early implementation, Cfront, was a preprocessor that translated “C with Classes” into ordinary C, which was then compiled by an existing C compiler. This strategy meant C with Classes could run on any machine with a C compiler — no new compiler infrastructure was required.

The key initial additions:

Classes — user-defined types with data members and member functions
Access control — public, private, protected visibility
Constructors and destructors — automatic initialization and cleanup
Derived classes — inheritance
Inline functions — function call overhead elimination

In 1983, Stroustrup renamed the language C++ (the ++ increment operator applied to C — “one better than C”). The name became official with the first edition of The C++ Programming Language in 1985.

// C++ (1985) — Simula's classes, C's performance
class Shape {
public:
    virtual double area() const = 0;  // pure virtual function
    virtual ~Shape() {}               // virtual destructor
};

class Circle : public Shape {
    double radius;
public:
    Circle(double r) : radius(r) {}   // constructor
    double area() const override {
        return 3.14159 * radius * radius;
    }
};

// Zero-overhead abstraction: no runtime cost unless virtual dispatch used

C++ templates (added early 1990s) allowed generic programming — algorithms and data structures written for arbitrary types. The Standard Template Library (STL), designed by Alexander Stepanov and incorporated into the C++ standard in 1994, provided generic containers (vector, list, map) and algorithms (sort, search, transform) that worked on any type satisfying specified requirements.

Zero-Overhead Abstraction

Stroustrup’s design principle was explicit: “You don’t pay for what you don’t use.” A C++ class with no virtual functions compiled to code with the same overhead as a C struct with functions. A template function, when instantiated, compiled to the same code as a hand-written function for that type. The abstractions were not runtime conveniences — they were compile-time transformations with no hidden cost. This principle made C++ viable in systems programming where Java’s runtime overhead would have been unacceptable.

The Design and Evolution of C++

In 1994, Stroustrup published “The Design and Evolution of C++” — an unusual book that explained not just what C++ was but why it was the way it was: which design decisions had been made deliberately, which were compromises, and which were mistakes that could not be fixed without breaking existing code.

The book was valuable precisely because it acknowledged complexity. C++ had accumulated features — multiple inheritance, virtual base classes, exception specifications, the auto_ptr debacle — that interacted in non-obvious ways. Stroustrup explained the reasoning behind each addition and the constraints that had prevented cleaner solutions.

The book also revealed Stroustrup’s governing philosophy: C++ should support multiple programming styles — procedural, object-oriented, generic, functional — because real programs often needed elements of each, and forcing a single style imposed unnecessary costs. This philosophy explained why C++ had so many ways to do the same thing, and why cleaning up the language was so difficult: every feature had been added for a reason, and removing it would break existing code.

Bell Labs, Morgan Stanley, Columbia

Stroustrup remained at AT&T’s Bell Labs (which became AT&T Labs after the 1996 split) until 2002, when he returned to academia as a chair professor of computer science at Texas A&M University (2002–2014). In 2014 he became a managing director in the technology division of Morgan Stanley — an unusual move that reflected C++’s dominance in financial systems — while also teaching at Columbia University, where he became a full professor in 2022.

Throughout this period, Stroustrup participated centrally in the C++ standards process. C++11 (2011) was the most significant update to the language since the original standard, adding move semantics, lambda expressions, smart pointers (effectively deprecating raw pointer ownership), and range-based for loops — features that addressed many of the common sources of bugs in pre-C++11 code. C++14, C++17, and C++20 followed with further refinements.

Dead End: Complexity as Accumulated Decision

C++’s evolution illustrates the tension between backward compatibility and language cleanliness. Every version of C++ must be backward compatible with all previous versions — code written in 1985 must still compile with a 2023 compiler, or the upgrade cost is unacceptable to the industry.

The Complexity Ratchet

The result is that every mistake made in early C++ versions — auto_ptr, complex exception specifications, three-way comparison inconsistencies — must be carried forward indefinitely, deprecated perhaps but never removed. C++11’s move semantics required understanding rvalue references, perfect forwarding, and the interplay with existing copy semantics. C++20’s modules require understanding the interaction with legacy header-based compilation. Each addition makes the language more powerful; each also makes it more difficult to master completely.

Newer languages — Java, C#, Go, Rust — chose clean breaks over backward compatibility, accepting the cost of migration in exchange for avoiding accumulated complexity. C++ cannot make this choice without abandoning its primary competitive advantage: the vast existing codebase. Stroustrup has consistently argued that the complexity is worth the cost for the domains C++ serves. Critics, including the designers of C’s successor languages, have consistently disagreed.

C++’s role in the OOP revolution is covered in The OOP Revolution. The language evolution context is in The Evolution of Language.