what – if anything – have we learned from c++? bjarne stroustrup morgan stanley, columbia, tamu
TRANSCRIPT
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
Stroustrup - Lang.Next 2014 4
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
Stroustrup - Lang.Next 2014 5
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
Stroustrup - Lang.Next 2014 7
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
Stroustrup - Lang.Next 2014 8
• 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
Stroustrup - Lang.Next 2014 9
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
Stroustrup - Lang.Next 2014 10
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)
Stroustrup - Lang.Next 2014 11
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”
Stroustrup - Lang.Next 2014 12
Control the Message
Conventional, 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
Stroustrup - Lang.Next 2014
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); // later
Stroustrup - Lang.Next 2014
Stroustrup - Lang.Next 2014 15
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
Stroustrup - Lang.Next 2014 16
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
Stroustrup - Lang.Next 2014 17
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
Stroustrup - Lang.Next 2014 18
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
Stroustrup - Lang.Next 2014
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”
Stroustrup - Lang.Next 2014
Stroustrup - Lang.Next 2014 21
C/C++ Compatibility
An important featureand
a massive problem
Stroustrup - Lang.Next 2014 22
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
Stroustrup - Lang.Next 2014 24
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
Stroustrup - Lang.Next 2014 26
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
Stroustrup - Lang.Next 2014 27
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
Stroustrup - Lang.Next 2014 28
C++
• Language features exist to serve programming styles– Generic programming– Resource management
Stroustrup - Lang.Next 2014 29
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)
Stroustrup - Lang.Next 2014 30
Templates
• A massive success in C++98, better in C++11, better still in C++14– STL containers
template<typename T> class vector { /* … */ };– STL algorithms
vector<int> v;// …sort(v.begin(),v.end());
– And much more
• Compile-time duck typing– Leading to template metaprogramming
Stroustrup - Lang.Next 2014 31
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"});
// …}
Stroustrup - Lang.Next 2014 32
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);
Stroustrup - Lang.Next 2014 33
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
Stroustrup - Lang.Next 2014 34
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
Stroustrup - Lang.Next 2014 35
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
Stroustrup - Lang.Next 2014 36
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
Stroustrup - Lang.Next 2014 37
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
Stroustrup - Lang.Next 2014 38
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
Stroustrup - Lang.Next 2014 39
Resource Management• Use constructors and a destructor
template<typename T>class Vector { // vector of elements of type T
Vector(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"};// …
}
Stroustrup - Lang.Next 2014 40
Move Semantics
• Return a MatrixMatrix 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:
Stroustrup - Lang.Next 2014 41
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();}
Stroustrup - Lang.Next 2014 43
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>)
Stroustrup - Lang.Next 2014 44
Challenges
45
Questions?
Key strengths:• software infrastructure• resource-constrained applications
C++: A light-weight abstractionprogramming language
Stroustrup - Lang.Next 2014
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)