Transcript What – if anything – have we learned from C++? Bjarne Stroustrup Morgan Stanley, Columbia, TAMU www.stroustrup.com.

What
– if anything –
have we learned from C++?
Bjarne Stroustrup
Morgan Stanley, Columbia, TAMU
www.stroustrup.com
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
3
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
4
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 specialpurpose, and too difficult for ordinary mortals
– “if you want a virtual function you cannot have done your analysis right”
Stroustrup - Lang.Next 2014
5
The roots of C++
Domain-specific
abstraction
General-purpose abstraction
Fortran
Cobol
Simula
Java
C++
C++11
C++14
Direct mapping to
hardware
Assembler
BCPL
C
Stroustrup - Lang.Next 2014
C#
6
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
7
Map to Hardware
• Primitive operations => instructions
– +, %, ->, [], (), …
value
• int, double, complex<double>, Date, …
handle
• vector, string, thread, Matrix, …
value
• Objects can be composed by simple concatenation:
– Arrays
– Classes/structs
value
handle
value
handle
• All maps to “raw memory”
Stroustrup - Lang.Next 2014
value
value
8
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 stack
and 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
9
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
10
Control the Message
Traditional (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
11
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
Stroustrup - Lang.Next 2014
12
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
13
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);
– X* p = new X(2);
• X a(2);
// later
// early (e.g., Simula)
// later
Stroustrup - Lang.Next 2014
14
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
15
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
16
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
17
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
Stroustrup - Lang.Next 2014
18
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
19
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
20
C/C++ Compatibility
An important feature
and
a massive problem
Stroustrup - Lang.Next 2014
21
Compatibility
• A (valid) alternative
–
–
–
–
–
–
Pascal
Turbo Pascal
Object Pascal
Pascal 2
Ada
…
• Modula
• Modula2
• Compatibility
– Is a feature
• Stability over decades
–
–
–
–
Is valuable
Is expensive
is hard
Hard to correct mistakes
– Modula3
• Oberon
• Oberon-2
• Oberon-7
Stroustrup - Lang.Next 2014
22
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 interfaces
Stroustrup - Lang.Next 2014
23
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, …
Stroustrup - Lang.Next 2014
24
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
25
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
26
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
27
C++
• Language features exist to serve programming styles
– Generic programming
– Resource management
Stroustrup - Lang.Next 2014
28
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
29
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
30
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
31
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
32
C++14 Concepts
• Error handling is simple (and fast)
template<Sortable Cont>
// Sortable is a Sequence with random access
void 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);
sort(lst);
// OK: a vector is Sortable
// Error at (this) point of use: Sortable requires random access
• Actual error message
error: ‘list<int>’ does not satisfy the constraint ‘Sortable’
• Additional information upon request
Stroustrup - Lang.Next 2014
33
Generic Programming is just Programming
• Traditional code
double sqrt(double d);
int x = 7;
double d2 = sqrt(x);
double d3 = sqrt(&x);
// C++84: accept any d that is a double
// fine: x can be used as a double
// error: &x is not a double
• Generic code
void sort(Sortable& c);
// C++14: accept any c that you can sort
// e.g., a container
vector<string> vs { "Hello", "new", "World" };
sort(vs);
// fine: vs can be used as a Container
sort(&vs);
// error: &vs is not a Container
Stroustrup - Lang.Next 2014
34
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
35
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
handle
• We don’t want complex resource management code
– Pointer manipulation
– Catch clauses
– Dispose idiom
Value
• A resource should have an owner
– Usually a “handle”
– A “handle” should present a well-defined and useful abstraction
Stroustrup - Lang.Next 2014
36
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
handle
Value
• Other C++ standard-library classes manage other resources
–
–
–
–
Not just memory
thread, lock_guard, …
istream, fstream, …
unique_ptr, shared_ptr
Garbage collection is
not sufficient
Stroustrup - Lang.Next 2014
37
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
38
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 elements
int 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
}
39
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 i
return r;
}
Matrix res = a+b;
• Define move a constructor for Matrix
– don’t copy; “steal the representation”
r:
res:
……..
Stroustrup - Lang.Next 2014
40
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";
Stroustrup - Lang.Next 2014
41
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>)
Stroustrup - Lang.Next 2014
43
Challenges
Stroustrup - Lang.Next 2014
44
Questions?
C++: A light-weight abstraction
programming language
Key strengths:
• software infrastructure
• resource-constrained applications
Stroustrup - Lang.Next 2014
Practice type-rich
programming
45
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)
Stroustrup - Modern C++ - Cambridge'14
46