Stroustrup What Have We Learned From C++ 2014

What
– if anything –
have we learned from C++?
Bjarne Stroustrup
Morgan Stanley, Columbia, TAMU
www.stroustrup.com
Abstract
• What is the essence of C++? Why did it succeed despite its
well‐understood flaws? What lessons ‐ if any ‐ can be applied
to newer languages?
• Themes: Social and technical factors. Resource management.
Generic programming. The importance of being inefficient.
The importance of syntax. How (not) to specify a language.
Standardization and compatibility. And no, I don't plan to
condemn C++ ‐ it is still the best language around for a lot of
things, and getting better. It just isn't anywhere near perfect
(even of its kind) or the best at everything ‐ and was never
claimed to be.
• 1 hour – 20‐30 slides – chatty delivery
Stroustrup ‐ Lang.Next 2014 2
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”
The roots of C++
Domain‐specific
abstraction
General‐purpose abstraction
Fortran
Cobol Simula Java
C++ C++11 C++14

Direct mapping to
hardware
C#
Assembler BCPL C
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
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
value handle
• All maps to “raw memory” 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 stack
and integers in dynamic storage
• Generic types and operations
– Using macros
• Yuck!
• Constructors and destructors
– Establishing invariants
• 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 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”
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
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
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
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
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
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
Compatibility
• A (valid) alternative • Compatibility
– Pascal – Is a feature
– Turbo Pascal • Stability over decades
– Object Pascal – Is valuable
– Pascal 2 – Is expensive
– Ada – is hard
– … – Hard to correct mistakes
• Modula
• Modula2
– Modula3
• Oberon
• Oberon‐2
• Oberon‐7
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
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, …
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”
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: 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 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
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 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); // OK: a vector is Sortable
sort(lst); // 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
Generic Programming is just Programming
• Traditional code
double sqrt(double d); // C++84: accept any d that is a double
int x = 7;
double d2 = sqrt(x); // fine: x can be used as a double
double d3 = sqrt(&x); // 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
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 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
Resources
• All C++ standard‐library containers manage their elements
– vector
– list, forward_list (singly‐linked list), … handle
– map, unordered_map (hash table),…
– set, multi_set, … Value
– string
• Other C++ standard‐library classes manage other resources
– Not just memory
– thread, lock_guard, …
– istream, fstream, … Garbage collection is
– unique_ptr, shared_ptr 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 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:
……..
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): auto mean(const Sequence& seq) {

n = 0.0 auto n = 0.0;
for x in seq: for (x : seq)
n += x n += x;
return n / len(seq) 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
Questions?
C++: A light‐weight abstraction
programming language
Key strengths: Practice type‐rich
• software infrastructure programming
• resource‐constrained applications
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
Tool chains
• Analysis tools
Syntax
• Syntax matters immensely
– Often in non‐obvious ways
– The C declarator syntax is an experiment that failed
• And is much beloved
– We can certainly do much better than C++’s syntax
• But would anyone really care?
Notes
• Inertia
– Encourage upgrade, 20 year old books and tools
• Committee work
• Mistakes
– Technical
– Social
• Direction
• “we want a small simple language”
– not really
• How (not) to specify a language
• How to get libraries
• What makes new features accepted?
• Distribution
• Community
• Resource management
• Standardization
– A necessary evil?
• ABI
• Packages
• Right problem, wrong solution
Then – early 80s
Languages – mostly designed in the 1970s
Ada Pascal
Algol* PL/1*
APL* Prolog
Assembler Simula*
Basic* Smalltalk
C Snobol*
Cobol*
Fortran*
Jovial*
Lisp
ML
Modula‐2 * presented at HOPL1 in 1978

Stroustrup What Have We Learned From C++ 2014

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Stroustrup What Have We Learned From C++ 2014

Uploaded by

Copyright:

Available Formats

What

Cobol Simula Java

C++ C++11 C++14

def mean(seq): auto mean(const Sequence& seq) {

You might also like