what – if anything – have we learned from c++?

What– if anything –

have we learned from C++?

Bjarne StroustrupMorgan Stanley, Columbia, TAMU

www.stroustrup.com

Stroustrup - Lang.Next 2014 3

Talk aims• A C++ talk• No boasts• No apologies• No attacks on other languages• Not restricted to language technicalities• Lessons that might be of use in the C++ world• Lessons that might be of wider use• A few concrete examples (not just motherhood & apple pie)• Not a complete memory dump• Open a dialog

• Obviously, I don’t know “all of the answers”• There is no best language for everything and everybody


Overview• C++

– Context, aims, and early design decisions• Language myths• Social and technical points

– Standardization, C compatibility, linking, …• Some key C++ design points

– Generic programming– Resource management


Then – early 1980s• Ken and Dennis had only just proved that semi-portable systems

programming could be done (almost completely) without assembler– C didn’t have function prototypes– “Lint” was the state of the art for static program analysis

• Most computers were <1MB and <1MHz– PDP11s were cool– VT100s were state of the art– A “personal computer” about $3000 (pre-inflation $$$)– The IBM PC was still in the future

• “Everybody” “knew” that “OO” was too slow, too special-purpose, and too difficult for ordinary mortals– “if you want a virtual function you cannot have done your analysis right”

6

The roots of C++

Assembler

Cobol

Fortran

C++

C

Simula

C++11

General-purpose abstraction

Domain-specific abstraction

Direct mapping to hardware

Java

C#BCPL

Stroustrup - Lang.Next 2014

C++14


C++ in two lines• What is C++?

– Direct map to hardware• of instructions and fundamental data types• Initially from C

– Zero-overhead abstraction• Classes with constructors and destructors, inheritance,

generic programming, function objects• Initially from Simula

• Much of the inspiration came from operating systems• What does C++ want to be when it grows up?

– See above– And be better at it for more modern hardware and techniques


• Primitive operations => instructions– +, %, ->, [], (), …

• int, double, complex<double>, Date, …

• vector, string, thread, Matrix, …

• Objects can be composed by simple concatenation:– Arrays– Classes/structs

• All maps to “raw memory”

Map to Hardware

value

handle

value

value

value

handle

handlevalue

value


Early Design Decisions (1979/80)• C compatibility

– Almost: function declarations– Leave no room for a language below (except assembler)

• Simula classes and class hierarchies– But all objects treated uniformly

• e.g., class objects on the stackand integers in dynamic storage

• Generic types and operations– Using macros

• Yuck!

• Constructors and destructors– Establishing invariants– Resource management

• Concurrency support through libraries


Later (1980s)• Overloading (1983)

– First: constructors, =, and functions– [], (), -> (. still missing)

• Exceptions– Throw object catch by type

• Use class hierarchies for grouping

• Templates– Types and functions– Type and value parameters– Type deduction for template arguments– Implicit instantiation

• Multiple inheritance– Especially useful for abstract classes (interfaces)


Control the MessageTraditional (from 1985 onwards) and far too complex:

• “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”


Control the MessageConventional, simple, popular, and wrong:

• “C++ is an Object-Oriented Language”

– Implies (to many)• C++ is poorly designed

– C compatibility is a mistake• Avoid most effective C++ techniques

– Classes not in hierarchies– Non-virtual functions– Free-standing functions– Generic programming

13

Language Myths*

• We want a simple language!– No, teachers want a simple language to teach

• In a semester or a quarter– No, researchers want a simple language to manipulate

• And extend– No, programmers what a simple language to start using

– Developers want a comprehensive language to use• Languages grow over time (massively)

– “Everybody” wants “a simpler language with just two more features”

* Not all myths are believed by all people Not all myths are untrue everywhere


14

Language Myths• We want an intuitive notation!

– People confuse the familiar for the simple• For new features, people insist on LOUD explicit syntax• For established features, people want terse notation

• Examples:– template<typename Container> void sort(Container&); // early

• void sort(Sortable& C); // later– try { f(x); } catch (Foo&) { … throw; } // early

// plus exception specifications• f(x); // later

– X* p = new X(2); // early (e.g., Simula)• X a(2); // laterStroustrup - Lang.Next 2014


Language Myths• We want an efficient language!

– No, most of the time programmers want a convenient language• However slow• Most programmers can’t even measure performance

– No, most researchers prefer an inefficient language• For which it is easy to devise optimizations and improvements

– For many applications we need an efficient language• But not for most parts of most applications• Distributed fat can be expensive


Language Myths• We want a language for writing reliable code

– No, many programmers are very intolerant about• Inconveniences imposed for reliability, performance, or security• The need to learn new concepts

– No, most programmers do not care• They will ship when their management says “ship!”• Lack of professionalism


Language Myths• There is a best language

– For everybody and for every task– One size fits all

• Oh, no!– These myths confound

• Education• Practice• Research• Language design• Management• Funding


Have a message• What is the language for?• Who is the language for?• What would make the language better?

– Define “better”– Be specific

• No language can be everything to everybody

• C++– Provides a direct map to hardware– Provides very general zero-overhead abstraction mechanisms– Primarily industrial

• Rewards good programmers

19

Standardization• A necessary evil?

– “You can’t have a major programming language controlled by a single company”• Actually, you can: Java, C#, …

• There are many kinds of standardization– ISO, ECMA, IEEE, W3C, …

• Long-term stability is a feature– You need a standards committee

• Vendor neutral– Important for some major users– Deprives C++ or development funds


20

How is ISO C++ Standardization Done

• 100 members at meetings, 200-300 more online– Primarily industry

• Democratic process– one company one vote– No technical qualifications for membership ($1280/year)– the aim is consensus

• Committees– add complexity (every feature can become a cancerous growth)– add delays– Have no coherent technical view– Ensure stability (a major feature)– Makes it hard to set and maintain direction– See “WG21”



C/C++ Compatibility

An important featureand

a massive problem


Compatibility• A (valid) alternative

– Pascal– Turbo Pascal– Object Pascal– Pascal 2– Ada– …

• Modula• Modula2

– Modula3• Oberon• Oberon-2• Oberon-7

• Compatibility– Is a feature

• Stability over decades– Is valuable– Is expensive– is hard– Hard to correct mistakes

23

Language Definition• How do you specify a language?

– Not English!• Though compiler writers love it

– Don’t define semantics of character sequences• At least go to ASTs

– Not bottom-up lambda calculus– Not virtual machine

• Formally describe key interfaces– Memory model– Concurrency model– Vector, List

• Formally verify the implementation of those interfacesStroustrup - Lang.Next 2014


Inter-language Interoperability• From day #1

– C linkage (and Fortran)– Interoperability was an explicit aim

• No decent linkage– of C++-specific constructs

• classes and templates

• No C++-specific dynamic linkage

• It takes two to tango– Interoperability is not just a C++ problem

• A massive problem– Dragging C++ down to the C level (interfaces)

• No standard-library types, no exceptions, …

25

Teaching - Massive Harm• “C fist”

– Low-level hacking with lots of pointers, casts, and macros• “Pure OOP”

– Deep class hierarchies with lots of virtual functions, pointers, casts, and macros

• And more

“use of a macro is a sign of a weakness in the design or in the language”Stroustrup - Lang.Next 2014


Community• The C++ user community has no real center

– Not even the ISO C++ committee• Many benefit without contributing• An ISO standards committee has limited scope

– A major failing• Somehow, I should have done better

• Lots of “little empires”– platform, compiler, library, tool supplier, consultants– Some “little empires” are not so little N*100K users

• Large corporations prefer languages they can own and control– No differential advantage in a shared, standardized language


Community• No owner

– Hard to set and maintain direction• No Resources

– Marketing– Libraries– Tool chains

• No– “Universal” conference– Magazine– Web site– Library distribution point

• 2013: The C++ Foundation


C++• Language features exist to serve programming styles

– Generic programming– Resource management


Generic Programming: Templates• 1980: Use macros to express generic types and functions• 1987 (and current) aims:

– Extremely general/flexible• “must be able to do much more than I can imagine”

– Zero-overhead• vector/Matrix/… to compete with C arrays

– Well-specified interfaces• Implying overloading, good error messages, and maybe separate compilation

• “two out of three ain’t bad”– But it isn’t really good either – it has kept me concerned/working for 20+ years– Concepts! (now available)


Templates• A massive success in C++98, better in C++11, better still in C++14

– STL containerstemplate<typename T> class vector { /* … */ };

– STL algorithmsvector<int> v;// …sort(v.begin(),v.end());

– And much more

• Compile-time duck typing– Leading to template metaprogramming


Algorithms and Function Objects• We parameterize

– container type– element type– criteria, actions, and algorithms– Type and value parameters,

• e.g. template<typename T, int N> class Buffer { … };

• Essential for flexibility and performance

void g(vector< string>& vs){

auto p = find_if(vs.begin(), vs.end(), [](auto x) {x<"Griffin"});

// …}


C++14 Concepts• Duck typing isn’t good enough• We need better-specified interfaces to templates

– State intent– Specify requirements for template arguments

• A concept is a predicate on a set of types and values• For example

template<typename Cont>requires Sortable<Cont>() // Sortable is a Sequence with random access

void sort(Cont& container);


C++14 Concepts• Error handling is simple (and fast)

template<Sortable Cont> // Sortable is a Sequence with random accessvoid sort(Cont& container);

vector<double> vec {1.2, 4.5, 0.5, -1.2};list<int> lst {1, 3, 5, 4, 6, 8,2};

sort(vec); // OK: a vector is Sortablesort(lst);// Error at (this) point of use: Sortable requires random access

• Actual error messageerror: ‘list<int>’ does not satisfy the constraint ‘Sortable’

• Additional information upon request


Generic Programming is just Programming

• Traditional codedouble sqrt(double d); // C++84: accept any d that is a doubleint x = 7;double d2 = sqrt(x); // fine: x can be used as a doubledouble d3 = sqrt(&x); // error: &x is not a double

• Generic codevoid sort(Sortable& c); // C++14: accept any c that you can sort

// e.g., a containervector<string> vs { "Hello", "new", "World" };sort(vs); // fine: vs can be used as a Containersort(&vs); // error: &vs is not a Container


Resources/Ownership• Garbage collection is neither necessary nor sufficient

– This needs proof

• Not necessary– I/we need to build many kinds of systems to prove that

• Not sufficient– Non-memory resources

• Thread-handles, file-handles, locks, sockets, containers holding non-memory resources

– Resource retention time– Distributed systems– NUMA memory


Resources• A resource is something that must be acquired and later released

– Explicitly or implicitly– Resource management should not be manual

• We don’t want leaks• We don’t want complex resource management code

– Pointer manipulation– Catch clauses– Dispose idiom

• A resource should have an owner– Usually a “handle”– A “handle” should present a well-defined and useful abstraction

handle

Value


Resources• All C++ standard-library containers manage their elements

– vector– list, forward_list (singly-linked list), …– map, unordered_map (hash table),…– set, multi_set, …– string

• Other C++ standard-library classes manage other resources– Not just memory– thread, lock_guard, …– istream, fstream, …– unique_ptr, shared_ptr

handle

Value

Garbage collection is not sufficient


Control• We control object lifetime/life-cycle

– Creation of objects: constructors– Destruction of objects: destructors– Copying of objects

• Construction and assignment• from on scope to another

– Movement of objects• Construction and assignment• from on scope to another

– Access to representation• At no cost compared to low-level hand coding


Resource Management• Use constructors and a destructor

template<typename T>class Vector { // vector of elements of type TVector(initializer_list<T>); // acquire memory; initialize elements~Vector(); // destroy elements; release memory// …private:T* elem; // pointer to elementsint sz; // number of elements};

void fct(){Vector<double> vd {1, 1.618, 3.14, 2.99e8};Vector<string> vs {"Strachey", "Richards", "Ritchie"};// …}


Move Semantics• Return a Matrix

Matrix operator+(const Matrix& a, const Matrix& b){Matrix r;// copy a[i]+b[i] into r[i] for each ireturn r;}Matrix res = a+b;

• Define move a constructor for Matrix– don’t copy; “steal the representation”

……..

res:

r:


Modern C++: C++11• As ever, what matters is how features work in combination

template<typename C, typename V>vector<Value_type<C>*> find_all(C& c, V v) // find all occurrences of v in c{vector<Value_type<C>*> res;for (auto& x : c)if (x==v)res.push_back(&x);return res;}

string m {"Mary had a little lamb"};for (const auto p : find_all(m,'a')) // p is a char*if (*p!='a')cerr << "string bug!\n";

Syntactic convergence?

Python C++14

def mean(seq): n = 0.0 for x in seq: n += x return n / len(seq)

auto mean(const Sequence& seq) { auto n = 0.0; for (x : seq) n += x; return n / seq.size();}


We can simplify• def mean(seq):

return sum(seq) / len(seq)

• auto mean(const Sequence& seq) {return accumulate(seq,{}) /

seq.size();}

• Nil of the appropriate type (Value_type<Sequence>)


Challenges

45

Questions?

Key strengths:• software infrastructure• resource-constrained applications

C++: A light-weight abstractionprogramming language


Practice type-richprogramming

Stroustrup - Modern C++ - Cambridge'14 46

C++ Information

• www.isocpp.org – The C++ Foundation’s website– Standards information, articles, user-group information

• Bjarne Stroustrup– A Tour of C++: All of C++ in 180 pages– The C++ Programming Language (4th edition): All of C++ in 1,300 pages– Programming: Principles and Practice using C++ (2nd edition)– www.stroustrup.com: Publication list, C++ libraries, FAQs, etc.

• The ISO Standards Committee site– Search for “WG21”– The ISO standard: All of C++ in 1,300 pages of “standardese”– All committee documents (incl. proposals)

http://www.isocpp.org/

http://www.stroustrup.com/

what – if anything – have we learned from c++?

Documents

c compatibilityalmost

c worldlessons

essence of c

best language

objectoriented language

hardwarestroustrup lang

librariesstroustrup

language technicalitieslessons