Evolving a language in and for the real world

C and C++, a case study

Bjarne Stroustrup Texas A&M University

www.stroustrup.com

Things change! • Today’s conditions for computing is radically different from

30 and 40 years ago • Most likely (and hopefully) today’s conditions for computing

is radically different from 30 and 40 years in the future • One lesson: Don’t assume today is “typical” or that today’s

tools and problems are ideal • Another lesson: Fortran, Cobol, C, and Lisp live on, so don’t

assume change is easy • We are not smarter than people 30 years ago, we just know

different things (note: not simply more things) and have better tools (built by people in the past)

Stroustrup History 3

1978 (or so) • Computers

– Memory, instruction speed, communications – Multi-processors, multiple instruction streams networks

• Software – Languages, compiler technology, interpreters

• Programmers – Fewer, on average better educated, more diverse technical backgrounds

Stroustrup History 4

Stroustrup History 5

Reading – HOPL2 :

• Dennis M. Ritchie: The Development of the C Language. http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

• B. Stroustrup: A History of C++: 1979-1991. http://www.stroustrup.com/hopl2.pdf

– HOPL3: • B. Stroustrup: Evolving a language in and for the real world: C++

1991-2006. http://www.stroustrup.com/hopl-almost-final.pdf

Stroustrup History 6

Time machine exercise • Pointing to a problem is in itself not much help

– We probably knew already

• Pointing to a solution that requires 100* the resources available isn’t much help – Would be seen as science fiction

• A good advice (in any situation) is something – That can be understood – Is concrete – Can be acted upon given the prevailing circumstances

• I appreciate attempts on narrative presentation and humor – Telling a story is the best way to get an idea across – Details can come later

Stroustrup History 7

Time Machine Exercise • To DMR:

– All implicit conversions should go in one direction • E.g. float->double is OK, double->float is not

– Make some conversions explicit • E.g., f = tofloat(d);

– Make the declarator syntax linear (e.g. all suffix) • E.g. let a : int • let f : ->(char->,char)->->char

– Make users specify function arguments • E.g. let sqrt: (double)->double;

– Don’t require struct in front of every use of a structure name – Observations

• Operator precedence grammars won’t be fashionable next year • Next year, you’ll have 128KB

Stroustrup History 8

Time Machine Exercise

• Remember – C is arguably the most successful and influential language

in the history of programming • Hundreds of languages failed at what C was trying to do

– More likely thousands of languages • DMR and friends got quite a few things right

• Many of you seriously underestimate what DMR and friends knew – Dozen’s of languages (incl. Lisp, Fortran, and PL/1) – Many operating systems – “Software crisis” coined by Doug McIlroy in 1969

Stroustrup History 9

Time Machine Exercise • To BS:

– Yes, performance really will remain important – Emphasize constructor/destructor pairs for general resource

management • Give it a nice name

– Use handles to move referred to objects • Rather than copying

– Provide explicit notation for abstract classes • E.g., abstract class X { … };

– Generic function and types are very important • More important than multiple inheritance

– Yes, you will soon be able to afford terminating exceptions Stroustrup History 10

C

• Write a portable operating system – Don’t use assembler (except very rarely)

• There were dozens of projects and languages aiming to do that – IBM – Wirth (PL/360, Pascal, Modula, .) – BCPL (Cambridge) – Algol 68 – Coral (UK defence) – …

Stroustrup History 11

HOPL 1: languages in 1968 or so • ALGOL 60 - Alan J. Perlis and Peter Naur • APL - Adin D. Falkoff and Kenneth E. Iverson • APT - Douglas T. Ross • BASIC - Thomas E. Kurtz • COBOL - Jean E. Sammet • FORTRAN - John Backus • GPSS - Geoffrey Gordon • JOSS - Charles L. Baker • JOVIAL - Jules I. Schwartz • LISP - John McCarthy • PL/I - George Radin • SIMULA - Kristen Nygaard • SNOBOL - Ralph E. Griswold

Stroustrup History 12

HOPL 2: languages in 1978 or so • Monitors and Concurrent Pascal - Per Brinch Hansen • Prolog - Alain Colmerauer and Phillipe Roussel • Icon - Ralph E. Griswold and Madge T. Griswold • Smalltalk - Alan C. Kay • ALGOL 68 - C. H. Lindsey • CLU - Barbara Liskov • Discrete Event Simulation programming languages - Richard E. Nance • Forth - Elizabeth Rather, Donald R. Colburn, and Charles H. Moore • C - Dennis Ritchie • FORMAC - Jean E. Sammet • Lisp - Guy L. Steele, Jr. and Richard P. Gabriel • C++ - Bjarne Stroustrup • Ada - William A. Whitaker • Pascal - N. Wirth

Stroustrup History 13

C

• Known techniques – Garbage collection – Range checking – Regular expressions (grep) – “scripting” with associative arrays (awk) – Interpretation – Several ways of representing strings – Several ways of representing arrays – Nested functions – Serious numerics (Fortran) – Early networking (Arpanet, local area networks) – Processes – …

Stroustrup History 14

C • Not (yet) C++89, Not K&R C

– No enumerations – No structure copy – Implicit int double sqrt(); /* function declaration: no argument types */ /* implicit int return type */ main(argc,argv) char **argv; /* argc is an int */ { int n = 2; printf("sqrt(%d)==%g\n", n, sqrt(n)); /* hope for a crash */ }

• The C reference manual was 41 book pages • K&R is a masterpiece • Unix is a masterpiece

Stroustrup History 15

Stroustrup History 16

Bell Labs – Murray Hill

17 Stroustrup/PPP - March'13

Stroustrup History 18

Questions • What is C++? • What was C++ meant to be? • Why did it succeed? • At what did it not succeed? • In which sense did it succeed?

• Or as a friend expressed it

– Why the **** didn’t C++ die • as everyone predicted and • as many powerful groups hoped is would?

– You simply couldn’t “just stay lucky” for 25 years!

Stroustrup History 19

Overview

• Background and aims • Getting into use 1980-1990: C with Classes and C++ • Standardization 1990-1997: C++98 • Standardization 2002-2008: C++0x • Looking back and ahead

Stroustrup History 20

Programming • Programming is the activity of solving problems and

expressing their solution in a form that can be executed by a computer and understood by people.

• “The devil is in the details” – What kind of problems? – What kind of people? – What kind of computer? – What constraints do we place on the solution?

• Performance/scalability • Comprehensibility/maintainability • Reliability

Stroustrup History 21

C++ Purpose • The purpose of a programming language is to help in the

design, implementation, and maintenance of good software and systems (experimentally or for real)

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

1979 1985 1988 1991 1995 2000 2004 2008

C++ users .

~400K

~3.25M

500 – first commercial release

Stroustrup History 22

Major areas of use • Infrastructure

– Telecommunications – Google – Microsoft applications and GUIs – Linux tools and GUIs – Cell phones – Micro electronics design and manufacturing – …

• Advanced applications – Mars Rovers – Marine diesel engines – Games – PhotoShop – Human genome project – Finance and trading – …

Stroustrup History 23

What’s distinctive about C++? • Stability

– Essential for real-world software – 1984-2007 (C++) – 1978-2007 (C and C with Classes)

• Non-proprietary – Yet almost universally supported – ISO standard from 1998

• Direct interface to other languages – Notably C, assembler, Fortran

• Abstraction + machine model – Zero overhead principle

• For basic operations (e.g. memory access) and abstraction mechanisms – User-defined types receive the same support as built-in types – Standard library written in the language itself

• And most non-standard libraries

Stroustrup History 24

Aims for C++ • Support real-world software developers

– “better software now” • by “better” I mean correct, maintainable, efficient, portable, …

• Change the way people think about software – Object-oriented programming – Generic programming – Resource management – Error handling

• Functional, not academic beauty – “Even I know how to design

a prettier language” • B.S. 1984 or so

Stroustrup History 25

Ideals

• The fundamental ideals for good design – Represent ideas directly in code – Represent independent ideas independently in code – Represent relationships among ideas directly in code

• Hierarchical • Parametric

– Combine ideas expressed in code freely • when and only when combinations make sense

• C++ – Make these ideals viable for the largest possible range of application areas

• “viable” includes “affordable” and “on available hardware” • “affordable” includes “performs as well as the gold standard in a given area”

– e.g. Fortran for scientific computation and C for systems programming • “viable” includes “in the hands of real-world programmers”

Stroustrup History 26

When did I adopt those ideals? • 1979: combine Simula’s ability to organize code with C’s

ability to deal with hardware – Simula: directly express ideas as classes and class hierarchies – Simula: rely heavily on statically checked interfaces

• “strong type checking” – C: access hardware directly and optimally

• pointers, arrays, memory layout, bit manipulation • 1979: address the need for generic programming

“parameterization with types” – to compensate for a weakness of Simula – But the techniques to do it well are still evolving

• C++0x provides “concepts” • 1980: provide explicit support for resource management

– Constructors and destructors • 1983-93: More detailed articulation

Stroustrup History 27

ISO Standard C++

• C++ is a general-purpose programming language with a bias towards systems programming that – is a better C – supports data abstraction – supports object-oriented programming – supports generic programming

• A multi-paradigm programming language

– The most effective styles use a combination of techniques

From about 1994

From mid-1983

From 1979-80

Stroustrup History 28

1% inspiration + 99% perspiration • Designing and implementing

• Compilers • Libraries • “Model applications”

• Experimenting with language and library features • Writing

• Tutorials • Documentation • Academic papers

• Discussing with users and would-be users • Early use of internet newsgroups

• Providing support • “help desk”, porting, distribution, project initiation, … • “whatever it takes”

• Keep going “forever”

Stroustrup History 29

Major failures • I failed to effectively articulate my ideals for the use of C++

• My views got drowned out by a “all good code is object-oriented” oversimplified worldview

• The C++ community failed to create a true center • The C++ conferences became OO conferences • Several large organizations/companies focused on isolating their users • No central/common website

– Publication outlet – Discussion forum – Library distribution

• I failed to ship a sufficiently good standard library with release 1.0 • Leading to a unstructured mess of foundation and other libraries • Heavy replication of effort

– e.g. more than 25 GUI libraries

• No marketing • C++ was/is completely invisible

– E.g. no “C++ inside” branding

Stroustrup History 30

But the code worked! (in real-world systems)

• Simple, efficient, general, and comprehensible code

class vector { public: vector(int s) ; // constructor: make vector with s elements ~vector(); // destructor: release resources double& operator[](int x); // element access // … }; void f(int s) { vector v(s); for (int i=0; i<v.size(); ++i) v[i] = i; // … }

Stroustrup History 31

Success and failure • A language/tool can succeed

– Where it is good enough for every parts of a social system • Ease of learning/training • Ease of installation • Integration with other parts of the system • Performance (in all dimensions) • Maintainability • Portability • Cost effectiveness (over years or decades) • …

• Being best in the world in one or two areas is not enough – But marketing is often based on highlighting (hyping) individual features – But teaching/training is often restricted to a few simplified examples

Stroustrup History 32

C++ ISO Standardization – Membership • About 22 nations

(8 to 12 at a meeting) – ANSI (US national committee)

hosts the technical meetings – Other nations have further

technical meetings • Membership have varied

– 100 to 200+ • 200+ members currently

– 40 to 100 at a meeting • ~60 currently

• Most members work in industry • Most are volunteers

– Even many of the company representatives • Most major platform, compiler, and library vendors are represented

– E.g., IBM, Intel, Microsoft, Sun • End users are underrepresented

Stroustrup History 33

C++ ISO Standardization – Process Formal, slow, bureaucratic, and democratic

– “the worst way, except for all the rest” (apologies to W. Churchill)

Most technical work happens – in “working groups” – electronically between meetings

Stroustrup History 34

C++ ISO Standardization – Results 1990 Start of standards effort 1998 ISO standard

– 22-0 vote 2003 Technical Corrigenda

– “bug fix release”; no new features Technical reports

– Library (2004) – Performance (2004) – Library2 (2010) – Modularity – Decimal floating point (2008)

2008 Registration draft for C++0x – Should lead to C++09 (maybe)

Stroustrup History 35

C++ standardization – why bother? • The ISO standards process is central

– C++ has no rich owner • who can dictate changes, pay for design, implementation, marketing, etc.

– The C++ standards committee is the central forum of the C++ community • Endless discussions among people who would never meet otherwise

– The committee receives massive feedback from a broad section of the community • Much of it industrial

– The committee is somewhat proactive • Adds features not previously available in the C++ world

– Standard support needed for mainstream use • Huge potential for improvement of application code • For (far too) many “if it isn’t in the standard it doesn’t exist”

– Significant defense against vendor lock-in

Stroustrup History 36

Interlocking themes • Stability and Compatibility

– “make the language much better but don’t break my code” • Scale

– Million-line projects became common – Specification – precise and complete – Portability

• Resource management – Invariants

• Type safety – Containers

• Performance – Compactness

• Equal support for user-defined and built-in types – Value types, scoped objects

• User skills required

Stroustrup History 37

Standardization: 1990-1997 • All early C++ features

– C and C++ compatibility – Plus templates and exceptions (designed pre-standardization) – Plus many minor features

• A standard library – the STL

• containers, algorithms, iterators, function objects – iostream, locale, string, bitset, complex, valarray

• The C++ standard library is – Huge compared to the standard C library – Minute compared to corporate foundation libraries

The major innovation in C++98

Stroustrup History 38

Resource management • Standard library containers

– with exception-safety guarantees (e.g., vector)

– the techniques can be used by every user (e.g., File_handle)

• No resources are leaked – Based on a simple and systematic

view of resource management • Exception safety guarantees • RAII

– Destructors do cleanup • guaranteed, implicitly

void f(string s) { vector<int> v; File_handle h(s,'r'); // … int x; while (cin>>x) { if (x<=0) throw Bad_value(x); v.push(x); } // … }

Stroustrup History 39

The STL • Ideal: The most general and most

efficient expression of an algorithm – Focus on algorithms – Separate algorithms from data – Go from the concrete to the abstract

• Not the other way – Use compile-time resolution to eliminate

overheads • Inlining and overloading

– Where needed, parameterize with policies • E.g. sorting criteria

Stroustrup History 40

STL example: find_if

• Definition template<class Iter, class Pred> Iter find_if(Iter first, Iter last, Pred p) { while (first!=last && !p(*first)) // while not at end and predicate not met ++first; // advance to next element return first; // return the element reached }

Stroustrup History 41

STL example: find_if • Use

pi = find_if(v.begin(), v.end(), Less_than<int>(42)); if (pi!=v.end()) { // found it! }

// find() is the special case of find_if() where the predicate is == ps = find(ls.begin(), ls.end(), "Stepanov"); if (ps!=ls.end()) { // found him! }

• Note: these techniques generalize to essentially all data structures, predicates, and algorithms

Stroustrup History 42

C/C++ compatibility • A constant sore point

– Separate standards committees • A tragedy

– Constant borrowing • Both ways • Often incompatibly

– Widely demanded by users • Rightfully so

– Widely despised by users • “Against OO” • “Against the spirit of C”

Stroustrup History 43

C++0x: 2002-2008 • Overall goals

– Make C++ a better language • for systems programming • for library building

– Make C++ easier to teach and learn • generalization • better libraries

• Massive pressure for – More language features – Stability / compatibility

• Incl. C compatibility • Insufficient pressure for

– More standard libraries • The committee doesn’t have the resources required for massive library

development – Better support for non-systems programming uses

Stroustrup History 44

C++0x: Areas of improvement • Machine model and concurrency

– Memory model – Threads library, futures – Atomic API – Thread-local storage

• Support for generic programming – concepts – auto, decltype, template aliases, Rvalue references, … – initialization

• Etc. – improved enums – long long, C99 character types, etc. – …

The major innovations in C++0x

Stroustrup History 45

C++0x examples // type deduction based on initializer // and lambda functions auto pi = find_if(v.begin(), v.end(), [] (int i) { return i<42; }); if (pi!=v.end()) { /* found it! */ } // General initializer lists: vector<double> v = { 2.3, 1, 6.7, 4.5 }; unordered_map<string,int> herd = { {"bison",32}, {"elk",73}, {"deer",87} }; // early checking and overloading based on concepts: sort(v); // sort the vector based on < sort(herd); // error: no sort criterion sort(herd, Compare_names()); // ok: use Compare_name as sorting criterion // a new for loop: for (auto x : v) cout<< x << endl;

Stroustrup History 46

Retrospective • At what did C++ succeed? And why? • At what did C++ not succeed? And why? • Is there a future for the ideals that underlie C++?

Stroustrup History 47

Why did C++ succeed? • Reasons

– Low-level access plus abstraction mechanisms • Performance • Direct access to real hardware • Very general zero-overhead abstraction

– C compatibility – A useful tool (from day #1) – Timing – Non-proprietary – ISO standard – Stable – Evolving

“Being best at one or two things is not enough, you must be good enough at everything someone consider important”

Stroustrup History 48

How did C++ succeed? • It evolved/grew

– Feedback loops are essential (both to and from users) – “every working large system is developed from a smaller working system”

• Unsurpassed for applications with complexity and resource constraints – If you have “infinite” computer resources, you can simplify beyond what

C++ allows • “the only thing I know of that grows faster than hardware performance is

human expectation” – B.S. (1980s) • Individual processor performance is not growing (or decreasing)

– If you have only minor complexity, you can use simpler languages

Stroustrup History 49

Non-reasons for C++ success • Just luck

• For 25 years!

• AT&T’s marketing might • Must be a joke

• It was first • Except for Ada, CommonLoops, Smalltalk, Eiffel,

Objective C, Modula-2, C, Fortran, ML, …

• Just C compatibility • Never 100%

• It was cheapest • Not for most of its lifetime (incl. all the early years)

These non-reasons are very popular

Stroustrup History 50

C++ technical handicaps • No standard GUI • No standard toolset • No massive standard library

– Compared to proprietary foundation libraries

• Not completely type safe – “C is a strongly typed, weakly checked language” – Dennis Ritchie

• No direct support for serialization (e.g. extensive meta-data)

• A large language • No single simple doctrine of use

– No, not everything is an object, for any definition of “object”

Each technical handicap has corresponding benefits

Stroustrup History 51

At what did C++ not succeed? (and why not?)

• Development and deployment of massive libraries designed to interoperate

• Think: Java, .Net • Think: reducing much programming to package selection

– Nobody took the lead – No central coordinating body – No funding

• No marketing • No “free” libraries (to simplify programming, buy market share)

– Competing corporations (plus GNU) – Possible technical reason: no direct support for serialization

Stroustrup History 52

Future • Lots of use

– C++0x – C++1x – …

• Is there a future for “the C++ model” beyond C++? – Direct map to hardware – Zero-overhead abstraction – Minimal run-time environment – Heavy use of stack – Destructor-based resource management

• Challenges – Small language (or at least much, much smaller) – Complete and enforced type safety – Concurrency and distribution

yes

I think it can be done

Stroustrup History 53

Thanks! • C and Simula

– Brian Kernighan – Doug McIlroy – Kristen Nygaard – Dennis Ritchie – …

• ISO C++ standards committee – Steve Clamage – Francis Glassborow – Andrew Koenig – Tom Plum – Herb Sutter – …

• C++ compiler, tools, and library builders – Beman Dawes – David Vandevoorde – …

• Application builders

Stroustrup History 54

More information • My HOPL-II and HOPL-III papers • The Design and Evolution of C++ (Addison Wesley 1994) • My home pages

– Papers, FAQs, libraries, applications, compilers, … • Search for “Bjarne” or “Stroustrup”

• The ISO C++ standard committee’s site: – All documents from 1994 onwards

• Search for “WG21”

• The Computer History Museum – Software preservation project’s C++ pages

• Early compilers and documentation, etc. – Search for “C++ Historical Sources Archive”