Trends and future of C++ Bjarne Stroustrup Texas A&M University http://www.research.att.com/~bs • Machine, Abstraction, and Resources • The Design of C++0x
May 22, 2015
Trends and future of C++
Bjarne StroustrupTexas A&M Universityhttp://www.research.att.com/~bs
• Machine, Abstraction, and Resources• The Design of C++0x
C++:Machine, Abstraction, and Resources
Bjarne StroustrupTexas A&M Universityhttp://www.research.att.com/~bs
Stroustrup - Madrid'11 4
Overview• “The gap:” systems programming• C++• Mapping to the machine• Low-overhead abstraction• Resource management
Infrastructure
• Bridging the abstraction gap
Stroustrup - Madrid'11 5
Application ApplicationApplication Application
Foundation/Infrastructure
hardware hardware hardware
“The gap”
Systems programming
• .Net• JVM• Model driven development environments• Browser• Scripting engine• Game engine• Some aspects of enterprise architectures• Some aspects of operating systems• Embedded systems architectures• …
Infrastructure – Examples
Stroustrup - Madrid'11 6
Infrastructure• Is a platform
– Differentiates corporations, communities, organizations
• Expensive to– Build , port , and maintain
• Designed, built, and maintained by expert developers– Differ from application developers in attitude and skills
• Critical for applications– Ease of development– Stability over time (sometimes decades)– Maintenance – Portability across hardware– Performance
Stroustrup - Madrid'11 7
Systems Programming• Not just bit-fiddling
– Not even mostly bit-fiddling
• Classical systems programming– Demanding on designers and programmers
• High complexity– Layering, Modularity
• Hardware differs and matters– Some code must differ even on different processors of the same architecture
• Concurrency– Memory architecture, Multi-cores, Physical distribution
• High reliability requirements– Typically 24/7
• Large programs/libraries/systems– N*100K lines Stroustrup - Madrid'11 8
Stroustrup - Madrid'11 9
Programming languages• A programming language exists to help people express ideas
– Programming language features exist to serve design and programming techniques
– The real measure of value is the number, novelty, and quality of applications
Programming Languages
10
Assembler
Cobol
Fortran
C++
C
Simula
C++0x
General-purpose abstraction
Domain-specific abstraction
Direct mapping to hardware
Java
C#BCPL
Stroustrup - Madrid'11
ISO Standard C++• C++98: ISO standard since 1998
– Millions of programmers– Billions of lines of code deployed– Massive support
• C++0x: next ISO standard– Probably 2011
• We have a “Final Committee Draft”
– Many language features already available• GCC, Microsoft, IBM, Apple, etc.
– Standard libraries widely available
Stroustrup - Madrid'11 11
12
Ideals• Work at the highest feasible level of abstraction
– More correct, comprehensible, and maintainable code
• Represent– concepts directly in code– independent concepts independently in code
• Represent relationships among concepts directly– For example
• Hierarchical relationships (object-oriented programming)• Parametric relationships (generic programming)
• Combine concepts– freely– but only when needed and it makes sense
Stroustrup - Madrid'11
13
C++ maps directly onto hardware• Mapping to the machine
– Simple and direct– Built-in types
• fit into registers• Matches machine instructions
• Abstraction– User-defined types are created by simple composition– Zero-overhead principle:
• what you don’t use you don’t pay for• What you do use, you couldn’t hand code any better
Stroustrup - Madrid'11
14
Memory model
Memory is sequences of objects addressed by pointers
Stroustrup - Madrid'11
15
Memory model (built-in type)• char• short• int• long• (long long)• float• double• long double• T* (pointer)• T& (implemented as pointer)
Stroustrup - Madrid'11
16
Memory model (“ordinary” class)class Point {
int x, y;// …
};
// sizeof(Point)==2*sizeof(int)
Point p12(1,2);
Point* p = new Point(1,2);
// memory used for “p”:sizeof(Point*)+sizeof(Point)+Heap_info
1
2
p12:
1
2
Heapinfo
p:
Stroustrup - Madrid'11
17
Memory model – class hierarchyclass Base {
int b;};
class Derived : public Base {int d:
};
Base x;Derived y;
b
b
d
x:
y:
Stroustrup - Madrid'11
18
Memory model (polymorphic type)
class Shape {public:
virtual void draw() = 0;virtual Point center() = 0;// …
};
Heapinfo
vptr
drawcenter
Circle’sdraw()
Circle’scenter()
vtbl:
Shape* p = new Circle(x,20);
Stroustrup - Madrid'11
p->draw();
19
Not all memory models are that direct• Consider a pair of coordinates
– class Coord { double x,y,z; /* operations */ };– pair<Coord> xy= { {1,2,3}, {4,5,6} };
1 2 3 4
1 2
xy:
references:
Likely size: 6 words(2*3 words)
Likely minimal size: 15 words(1+(2+2)+2*(2+3) words)
“pure object-oriented” layout:
C++ layout:
reference:
5 6
3
4 5 6
Stroustrup - Madrid'11
But does it matter?• Memories are infinitely large (almost )• Processors are infinitely fast (almost )• We can use infinitely many processors (almost )
• For which size of sequence is a list faster than a vector?
Stroustrup - Madrid'11 20
1 2 9 15 19 22
5Ordered sequence:
insert:
But does in matter? (it does)
Stroustrup - Madrid'11 21
• “Let them eat cache!”– Compactness of vector vs. list– Streaming vs. Random access– Details are very architecture dependent
Abstraction• Simple user-defined types (“concrete types”)
– classes• Amazingly flexible• Zero overhead (time and space)
• Hierarchical organization (“abstract types”)– Abstract classes, virtual functions
• Fixed minimal overhead
– Class hierarchies, virtual functions• Object-oriented programming• Fixed minimal overhead
• Parameterized abstractions (“generic types and functions”)– Templates
• Generic programming• Amazingly flexible• Zero overhead (time and space)
Stroustrup - Madrid'11 22
A class – definedclass vector { // simple vector of doublepublic: // interface:
// a constructor establishes the class invariant (acquiring resources as needed):vector(); // constructor: empty vectorvector(initializer_list<double>); // constructor: initialize from a list~vector(); // destructor for cleanup
double& operator[](int i); // range checked accessconst double& operator[](int i) const; // access to immutable vectorint size() const;
// copy and move operationsprivate: // representation:
int sz;double* p;
}; Stroustrup - Madrid'11 23
Think of vector as a resource handle
A generic class – used• “Our” vector is just an ordinary type used like any other type
vector v1; // global variablesvector s2 = { 1, 2, 3, 4 };
void f(const vector& v) // arguments and local variables{
for (int i = 0; i<v.size(); ++i) cout << v[i] << ‘\n’;vector s3 = { 1, 2, 3, 5, 8, 13 };// …
}
struct S {vector s1; // class membersvector s2;
}; Stroustrup - Madrid'11 24
No explicit resource management
A class - implementedclass vector { // simple vector of doublepublic:
vector() :sz(0), elem(0) { }vector(initializer_list<double> il) :sz(il.size()), elem(new double[sz])
{ uninitialized_copy(il.begin(), il.end(), elem); }~vector() { delete[] elem; }double& operator[](int i)
{ if (i<0||sz<=i) throw out_of_range(); return elem[i]; }const double& operator[](int i) const; // access to immutable vectorint size() const { return sz; }// copy and move operations
private:int sz;double* elem;
}; Stroustrup - Madrid'11 25
No run-time support system “magic”
A class – made generictemplate<class T> class vector { // simple vector of Tpublic:
vector() :sz(0), elem(0) { }vector(initializer_list<T> il) :sz(il.size()), elem(new T[sz])
{ uninitialized_copy(il.begin(), il.end(), elem); }~vector() { delete[] elem; }T& operator[](int i)
{ if (i<0||sz<=i) throw out_of_range(); return elem[i]; }const T& operator[](int i) const; // access to immutable vectorint size() const { return sz; }// copy and move operations
private:int sz;T* elem;
}; Stroustrup - Madrid'11 26
No overheads compared to the non-generic version
A generic class – used• “Our” vector is used just like any other type, taking its element
type as an argument– No fancy runtime system– No overheads (time or space) compare to hand codingvector<int> vi;vector<double> vd = { 1.0, 2, 3.14 }; // exactly like the non-parameterized versionvector<string> vs = {"Hello", "New", "World" };vector<vector<Coord>> vvc = {
{ {1,2,3}, {4,5,6} },{},{ {2,3,4}, {3,4,5}, {4,5,6}, {5,6,7} }
};
Stroustrup - Madrid'11 27
C++0x
In real-world code• We use the standard-library vector
– Fundamentally similar to “our” vector• same mapping to hardware• Same abstraction mechanisms
– More refined that “our” vector– As efficient (same map to hardware)
• or better
• Or we use an industry, corporation, project “standard” container– Designed to cater for special needs
• Build our own– Using the same facilities and techniques used for the standard library
• There are tens of thousands of libraries “out there”– But no really good way of finding them
Stroustrup - Madrid'11 28
Maintaining abstraction close to the hardware
• Compile-time resolution– Templates– Overloading
• Inline functions– Saves time and space for tiny functions– Requires use of values (minimize the use of pointers/indirections)
• Constant expression evaluation
Stroustrup - Madrid'11 29
30
Abstraction is affordable
• Read and sort floating-point numbers– C: read using stdio; qsort(buf,n,sizeof(double),compare)– C++: read using iostream; sort(v.begin(),v.end());
#elements C++ C C/C++ ratio500,000 2.5 5.1 2.045,000,000 27.4 126.6 4.62
• How?– clean algorithm– inlining
(Details: May’99 issue of C/C++ Journal; http://www.research.att.com/~bs/papers.html)
slow
fast
Stroustrup - Madrid'11
31
Engine example
• MAN – B&W marine diesel engine– Up to 132,340Hp– Has been deployed in very large ships for a couple of years
Stroustrup - Madrid'11
32
Engine exampleStatusType<FixPoint16> EngineClass::InternalLoadEstimation(
const StatusType<FixPoint16>& UnsigRelSpeed,const StatusType<FixPoint16>& FuelIndex)
{StatusType<FixPoint16> sl =UnsigRelSpeed*FuelIndex;
StatusType<FixPoint16> IntLoad =sl*(PointSevenFive+sl*(PointFiveFour-PointTwoSeven*sl))- PointZeroTwo*UnsigRelSpeed*UnsigRelSpeed*UnsigRelSpeed;
IntLoad=IntLoad*NoFuelCylCorrFactor.Get();
if (IntLoad.GetValue()<FixPoint16ZeroValue)IntLoad=sFIXPOINT16_0;
return IntLoad;}
Stroustrup - Madrid'11
What is a “resource”?• A resource is something
– You acquire– You use– You release/free– Any or all of those steps can be implicit
• Examples– Free store (heap) memory– Sockets– Locks– Files– Threads
33Stroustrup - Madrid'11
Handle (local)
Resource(shared over time)
34
Managing Resources// unsafe, naïve use (common in all languages):
void f(const char* p){
FILE* f = fopen(p,"r"); // acquire// use ffclose(f); // release
}
Stroustrup - Madrid'11
35
Managing Resources// naïve fix:
void f(const char* p){
FILE* f = 0;try {
f = fopen(p, "r");// use f
}catch (…) { // handle every exception
if (f) fclose(f);throw;
}if (f) fclose(f);
}
Stroustrup - Madrid'11
36
Managing Resources// use an object to represent a resource (RAII ==“resource acquisition is initialization”)
class File_handle { // belongs in some support libraryFILE* p;
public:File_handle(const string& s, const char* r) // constructor: acquire{
p = fopen(s.c_str(),r);if (p==0) throw File_error(s,r);
}
~File_handle() { fclose(p); } // destructor: release
// copy and move operations// access functions
};
void f(string s){
File_handle f(s, "r"); // simpler than “naïve use”// use f
}Stroustrup - Madrid'11
Simplified conventional locking• A lock represents local ownership of a resource (the mutex)
std::mutex m;int sh; // shared data
void f(){
// ...std::unique_lock<mutex> lck(m); // grab (acquire) the mutex// manipulate shared data:sh+=1;
} // implicitly release the mutex
Stroustrup - Madrid'11 37
C++0x
Summary• Focus on mapping from “high-level” applications to hardware
– One critical focus among many– The complexity of this mapping is easily underestimated
• Work at the highest feasible level of abstraction– For correctness, maintainability, portability, and performance
• A programming language can help– A suitable programming language– In the hands of competent programmers– Good language use is essential (IMO)
• Rely on libraries– Define and rely on explicit abstractions– Represent resources directly
• Stay type safeStroustrup - Madrid'11 38
39
C++ for safety-critical uses
• JSF++ (a subset of a superset of C++)– Stricter than any C subset (and far more flexible)– Type safe
CC++ JSF++
MISRA C (a subset of C)
General strategy: Use a subset of superset
Stroustrup - Madrid'11
Stroustrup - Madrid'11 40
More C++ information• My home pages
– Papers, FAQs, libraries, applications, compilers, …• Search for “Bjarne” or “Stroustrup”
• C++0x:– The ISO C++ standard committee’s site:
• All documents from 1994 onwards– Search for “WG21”
• Design and evolution of of C++– My HOPL-II and HOPL-III papers– The Design and Evolution of C++ (Addison Wesley 1994)– The Computer History Museum
• Software preservation project’s C++ pages– Early compilers and documentation, etc.
» http://www.softwarepreservation.org/projects/c_plus_plus/» Search for “C++ Historical Sources Archive”
Stroustrup - Madrid'11 41
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
The Design of C++0x
Bjarne StroustrupTexas A&M Universityhttp://www.research.att.com/~bs
Stroustrup - Madrid'11
Overview• Aims, Ideals, and history• C++• Design rules for C++0x
– With examples• Case study
– Initialization
44
Stroustrup - Madrid'11
Programming languages• A programming language exists to help people express ideas
• Programming language features exist to serve design and programming techniques
• The primary value of a programming language is in the applications written in it
• The quest for better languages has been long and must continue45
Programming Languages
Assembler
Cobol
Fortran
C++
C
Simula
C++0x
General-purpose abstraction
Domain-specific abstraction
Direct mapping to hardware
Java
C#BCPL
Stroustrup - Madrid'11 46
Ideals• Work at the highest feasible level of abstraction
– More general, correct, comprehensible, and maintainable code
• Represent– concepts directly in code– independent concepts independently in code
• Represent relationships among concepts directly– For example
• Hierarchical relationships (object-oriented programming)• Parametric relationships (generic programming)
• Combine concepts– freely– but only when needed and it makes sense
Stroustrup - Madrid'11 47
Stroustrup - Madrid'11
C with Classes –1980• General abstraction mechanisms to cope with complexity
– From Simula• General close-to-hardware machine model for efficiency
– From C
• Became C++ in 1984– Commercial release 1985
• Non-commercial source license: $75– ISO standard 1998– C++0x: Final Draft Standard 2010
• 2nd ISO standard 200x (‘x’ is hex )
48
Stroustrup - Madrid'11
C++ ISO Standardization• Slow, bureaucratic,
democratic, formal process– “the worst way, except for all the rest”
• (apologies to W. Churchill)
• About 22 nations(5 to 12 at a meeting)
• Membership have varied– 100 to 200+
• 200+ members currently– 40 to 100 at a meeting
• ~60 currently
• Most members work in industry• Most members 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
52
Design?• Can a committee design?
– No (at least not much)– Few people consider or care
for the whole language• Is C++0x designed
– Yes• Well, mostly: You can see
traces of different personalities in C++0x
• Committees– Discuss– Bring up problems– “Polish”– Are brakes on innovation
Stroustrup - Madrid'11 53
Overall goals for C++0x
• Make C++ a better language for systems programming and library building– Rather than providing specialized
facilities for a particular sub-community (e.g. numeric computation or Windows-style application development)
– Build directly on C++’s contributions to systems programming
• Make C++ easier to teach and learn– Through increased uniformity, stronger guarantees, and
facilities supportive of novices (there will always be more novices than experts)
Stroustrup - Madrid'11 54
C++0x
• ‘x’ may be hex, but C++0x is not science fiction– Every feature is implemented somewhere
• E.g. GCC 4.6: Rvalues, Variadic templates, Initializer lists, Static assertions, auto, New function declarator syntax, Lambdas, Right angle brackets, Extern templates, Strongly-typed enums, constexpr, Delegating constructors (patch), Raw string literals, Defaulted and deleted functions, Inline namespaces, noexcept, Local and unnamed types as template arguments, range-for
– Standard library components are shipping widely• E.g. GCC, Microsoft, Boost
– The last design points have been settled• We are processing requests from National Standards Bodies
Stroustrup - Madrid'11 55
Rules of thumb / Ideals• Integrating features to work in combination is the key
– And the most work– The whole is much more than the simple sum of its part
• Maintain stability and compatibility• Prefer libraries to language extensions• Prefer generality to specialization• Support both experts and novices• Increase type safety• Improve performance and ability to work directly with hardware• Make only changes that change the way people think• Fit into the real world
Stroustrup - Madrid'11 56
Maintain stability and compatibility• “Don’t break my code!”
– There are billions of lines of code “out there”• 1 billion == 1000 million
– There are millions of C++ programmers “out there”
• “Absolutely no incompatibilities” leads to ugliness– We introduce new keywords as needed: auto (recycled), decltype,
constexpr, thread_local, nullptr– Example of incompatibility:
static_assert(4<=sizeof(int),"error: small ints");
Stroustrup - Madrid'11 57
Support both experts and novices• Example: minor syntax cleanup
vector<list<int>> vl; // note the “missing space”
• Example: get type from initializerauto v = 7.2; // v is a double (because 7.2. is a double)
• Example: simplified iterationfor (auto x : v) cout << x <<'\n';
• Note: Experts don’t easily appreciate the needs of novices– Example of what we couldn’t get just now
string s = "12.3";double x = lexical_cast<double>(s); // extract value from string
Stroustrup - Madrid'11 58
Prefer libraries to language extensions• Libraries deliver more functionality• Libraries are immediately useful• Problem: Enthusiasts prefer language features
– see library as 2nd best
• Example: New library components– std::thread, std::future, …
• Threads ABI; not thread built-in type– std::unordered_map, std::regex, …
• Not built-in associative array
Stroustrup - Madrid'11 59
Prefer generality to specialization• Example: Prefer improvements to abstraction mechanisms
over separate new features– Inherited constructor
template<class T> class Vector : std::vector<T> {using vector::vector<T>; // inherit all constructors// …
};– Move semantics supported by rvalue references
template<class T> class vector {// …void push_back(T&& x); // move x into vector
// avoid copy if possible};
• Problem: people love small isolated featuresStroustrup - Madrid'11 60
Move semantics• Often we don’t want two copies, we just want to move a value
vector<int> make_test_sequence(int n){
vector<int> res;for (int i=0; i<n; ++i) res.push_back(rand_int());return res; // move, not copy
}
vector<int> seq = make_test_sequence(1000000); // no copies
• New idiom for arithmetic operations:– Matrix operator+(const Matrix&, const Matrix&);– a = b+c+d+e; // no copies
Stroustrup - Madrid'11
Not a reference
61
Increase type safety• Approximate the unachievable ideal
– Example: Strongly-typed enumerationsenum class Color { red, blue, green };int x = Color::red; // error: no Color->int conversionColor y = 7; // error: no int->Color conversionColor z = red; // error: red not in scopeColor c = Color::red; // fine
– Example: Support for general resource management• std::unique_ptr (for ownership)• std::shared_ptr (for sharing)• Garbage collection ABI
Stroustrup - Madrid'11 62
Improve performance and the ability to work directly with hardware
• Embedded systems programming is very important– Example: address array/pointer problems
• array<int,7> s; // fixed-sized array
– Example: Generalized constant expressions (think ROM)constexpr int abs(int i) { return (0<=i) ? i : -i; } // can be constant expression
struct Point { // “literal type” can be used in constant expressionint x, y;constexpr Point(int xx, int yy) : x{xx}, y{yy} { }
};
constexpr Point p1{1,2}; // must be evaluated at compile time: okconstexpr Point p2{p1.y,abs(x)}; // ok?: is x is a constant expression?
Stroustrup - Madrid'11 63
Make only changes that changethe way people think
• Think/remember:– Object-oriented programming– Generic programming– Concurrency– …
• But, most people prefer to fiddle with details– So there are dozens of small improvements
• All useful somewhere• long long, static_assert, raw literals, thread_local, unicode types, …
– Example: A null pointer keywordvoid f(int);void f(char*);f(0); // call f(int);f(nullptr); // call f(char*);
Stroustrup - Madrid'11 64
Fit into the real world• Example: Existing compilers and tools must evolve
– Simple complete replacement is impossible– Tool chains are huge and expensive– There are more tools than you can imagine– C++ exists on many platforms
• So the tool chain problems occur N times– (for each of M tools)
• Example: Education– Teachers, courses, and textbooks
• Often mired in 1970s thinking (“C is the perfect language”)• Often mired in 1980s thinking (“OOP: Rah! Rah!! Rah!!!”)
– “We” haven’t completely caught up with C++98!• “legacy code breeds more legacy code”
Stroustrup - Madrid'11 65
Areas of language change• Machine model and concurrency Model
– Threads library (std::thread)– Atomics ABI– Thread-local storage (thread_local)– Asynchronous message buffer (std::future)
• Support for generic programming– (no concepts )– uniform initialization– auto, decltype, lambdas, template aliases, move semantics, variadic
templates, range-for, …• Etc.
– static_assert– improved enums– long long, C99 character types, etc.– … Stroustrup - Madrid'11 66
Standard Library Improvements• New containers
– Hash Tables (unordered_map, etc.)– Singly-linked list (forward_list)– Fixed-sized array (array)
• Container improvements– Move semantics (e.g. push_back)– Intializer-list constructors– Emplace operations– Scoped allocators
• More algorithms (just a few)• Concurrency support
– thread, mutex, lock, …– future, async, …– Atomic types
• Garbage collection ABI
Stroustrup - Madrid'11 67
Standard Library Improvements• Regular Expressions (regex)• General-purpose Smart Pointers (unique_ptr, shared_ptr, …)• Extensible Random Number Facility• Enhanced Binder and function wrapper (bind and function)• Mathematical Special Functions• Tuple Types (tuple)• Type Traits (lots)
Stroustrup - Madrid'11 68
What is C++?
A multi-paradigm programming language
It’s C!
A hybrid language
An object-oriented programming language
Templatemeta-programming!
A random collection of features
Embedded systems programming language
Low level!
Buffer overflows
Too big!
Supportsgeneric programming
Stroustrup - Madrid'11 69
C++0x• It feels like a new language
– Compared to C++98• It’s not just “object oriented”
– Many of the key user-defined abstractions are not objects• Types• Classifications and manipulation of types (types of types)
– I miss “concepts”
• Algorithms (generalized versions of computation)• Resources and resource lifetimes
• The pieces fit together much better than they used to
Stroustrup - Madrid'11 70
C++Key strength:
Building software infrastructures and resource-constrained applications
A light-weight abstractionprogramming language
Stroustrup - Madrid'11 71
So, what does “light-weight abstraction” mean?
• The design of programs focused on the design, implementation, and use of abstractions– Often abstractions are organized into libraries
• So this style of development has been called “library-oriented”
• C++ emphasis– Flexible static type system– Small abstractions– Performance (in time and space)– Ability to work close to the hardware
Stroustrup - Madrid'11 72
Case studies
• Initialization– “language maintenance”
• Simplification through generalization
• Concurrency– “a necessity”
• Design under severe constraints
Stroustrup - Madrid'11 73
74
Case study: Initializers• The problems
– #1: Irregularity– #2: Lack of adequate variable-length list mechanism– #3: Narrowing
• Constraints– About 35 years of history
• The bigger picture– Uniform initialization syntax and semantics needed
• The solution– { } uniform initialization
• Uniform syntax• Uniform semantics
Stroustrup - Madrid'11
75
Problem #1: irregularity• There are four notations
– int a = 2; // “assignment style”– int aa[] = { 2, 3 }; // “list style”– complex z(1,2); // “functional style”– x = Ptr(y); // “functional style” for conversion/cast/construction
• No notation can be used everywhere– p = (new int = 2); // error: no = initialization for free store objects– complex z{1,2}; // error: complex has a constructor– int aa[](2,3); // error: an array doesn’t have a constructor– x = Ptr{3}; // syntax error: you can’t cast from a list
Stroustrup - Madrid'11
76
Problem #1: irregularity
• Sometimes, the syntax is inconsistent/confusingint a(1); // variable definitionint b(); // function declarationint b(foo); // variable definition or function declaration
• We can’t use initializer lists except in a few casesstring a[] = { "foo", " bar" }; // ok: initialize array variablevector<string> v = { "foo", " bar" }; // error: initialize vector variable
void f(string a[]);f( { "foo", " bar" } ); // error: initializer array argument
Stroustrup - Madrid'11
77
Is irregularity a real problem?• Yes, a major source of confusion and bugs• Violates a fundamental C++ design principle:
– Provide uniform support for types (user-defined and built-in)• Can it be solved by restriction?
– No existing syntax can be used in all casesint a [] = { 1,2,3 }; // can’t use () herecomplex<double> z(1,2); // can’t use { } herestruct S { double x,y; } s = {1,2}; // can’t use ( ) hereint* p = new int(4); // can’t use { } or = here
– No existing syntax has the same semantics in all casestypedef char* Pchar;Pchar p(7); // error (good!)Pchar p = Pchar(7); // “legal” (ouch!)
Stroustrup - Madrid'11
78
Problem #2: list workarounds• Initialize a vector (using push_back)
– Clumsy and indirect
template<class T> class vector {// …void push_back(const T&) { /* … */ }// …
};
vector<double> v;v.push_back(1); v.push_back(2); v.push_back(3.4);
• Violates a fundamental C++ design principle:– Support fundamental notions directly (“state intent”)
Stroustrup - Madrid'11
79
Problem #2: list workarounds• Initialize vector (using general iterator constructor)
– Awkward, error-prone, and indirect– Spurious use of (unsafe) array
template<class T> class vector {// …template <class Iter>
vector(Iter first, Iter last) { /* … */ }// …
};
int a[ ] = { 1, 2, 3.4 }; // bugvector<double> v(a, a+sizeof(a)/sizeof(int)); // hazard
• Violates a fundamental C++ design principle:– Provide uniform support for types (user-defined and built-in)
Stroustrup - Madrid'11
80
C++0x: initializer lists
• An initializer-list constructor– defines the meaning of an initializer list for a type
template<class T> class vector {// …vector(std::initializer_list<T>); // initializer list constructor// …
};
vector<double> v = { 1, 2, 3.4 };
vector<string> geek_heros = {"Dahl", "Kernighan", "McIlroy", "Nygaard ", "Ritchie", "Stepanov"
};Stroustrup - Madrid'11
81
C++0x: initializer lists• Not just for templates and constructors
– but std::initializer list is simple – does just one thing well
void f(int, std::initializer_list<int>, int);
f(1, {2,3,4}, 5);f(42, {1,a,3,b,c,d,x+y,0,g(x+a),0,0,3}, 1066);
Stroustrup - Madrid'11
82
Uniform initialization syntax• Every form of initialization can accept the { … } syntax
X x1 = X{1,2}; X x2 = {1,2}; // the = is optionalX x3{1,2}; X* p2 = new X{1,2};
struct D : X {D(int x, int y) :X{x,y} { /* … */ };
};
struct S {int a[3];S(int x, int y, int z) :a{x,y,z} { /* … */ }; // solution to old problem
};Stroustrup - Madrid'11
83
Uniform initialization semantics• X { a } constructs the same value in every context
– { } initialization gives the same result in all places where it is legalX x{a}; X* p = new X{a};z = X{a}; // use as castf({a}); // function argument (of type X)return {a}; // function return value (function returning X)…
• X { … } is always an initialization– X var{}; // no operand; default initialization
• Not a function definition like X var();– X var{a}; // one operand
• Never a function definition like X var(a); (if a is a type name)Stroustrup - Madrid'11
84
Initialization problem #3: narrowing• C++98 implicitly truncates
int x = 7.3; // Ouch!char c = 2001; // Ouch!int a[] = { 1,2,3.4,5,6 }; // Ouch!
void f1(int); f1(7.3); // Ouch!void f2(char); f2(2001); // Ouch!void f3(int[]); f3({ 1,2,3.4,5,6 }); // oh! Another problem
• A leftover from before C had casts!• Principle violated: Type safety• Solution:
– C++0x { } initialization doesn’t narrow.• all examples above are caught
Stroustrup - Madrid'11
85
Uniform Initialization• Example
Table phone_numbers = {{ "Donald Duck", 2015551234 },{ “Mike Doonesbury", 9794566089 },{ "Kell Dewclaw", 1123581321 }
};
• What is Table?– a map? An array of structs? A vector of pairs? My own class with a
constructor? A struct needing aggregate initialization? Something else? – We don’t care as long as it can be constructed using a C-style string
and an integer. – Those numbers cannot get truncated
Stroustrup - Madrid'11
Concurrency support• Memory model
– To guarantee our usual assumptions
• Support for concurrent systems programming– Atomic types for implementing concurrency support features
• “Here be dragons”• Lock-free programming
– Thread, mutex, lock, …• RAII for locking• Type safe
• A single higher-level model– async() and futures
Spring'11 Stroustrup 86
What we want• Ease of programming
– Writing correct concurrent code is hard– Modern hardware is concurrent in more way than you imagine
• Uncompromising performance– But for what?
• Portability – Preferably portable performance
• System level interoperability– C++ shares threads with other languages and with the OSs
Stroustrup - Madrid'11 87
We can’t get everything• No one concurrency model is best for everything• We can’t get all that much
– C++0x is not a research project– WG21 has very few resources (time, people)– “Don’t break my code!”
• “C++ is a systems programming language”– (among other things) implies serious constraints
Stroustrup - Madrid'11 88
Memory model• A memory model is an agreement between the machine
architects and the compiler writers to ensure that most programmers do not have to think about the details of modern computer hardware.// thread 1:char c;c = 1;int x = c;
x==1 and y==1 as anyone would expect(but don’t try that for two bitfields of the same word)
Stroustrup - Madrid'11 89
// thread 2:char b;b = 1;int y = b;
c: b:
Atomics (“here be dragons!”)
• Components for fine-grained atomic access– provided via operations on atomic objects (in <cstdatomic>)– Low-level, messy, and shared with C (making the notation messy)– what you need for lock-free programming– what you need to implement std::thread, std::mutex, etc.– Several synchronization models, CAS, fences, …enum memory_order { // regular (non-atomic) memory synchronization order
memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_release, memory_order_acq_rel, memory_order_seq_cst
};C atomic_load_explicit(const volatile A* object, memory_order);void atomic_store_explicit(volatile A *object, C desired, memory_order order);bool atomic_compare_exchange_weak_explicit(volatile A* object, C * expected, C
desired, memory_order success, memory_order failure);// … lots more …
Stroustrup - Madrid'11 91
Threading
• You can – wait for a thread for a specified time – control access to some data by mutual exclusion – control access to some data using locks– wait for an action of another task using a condition variable – return a value from a thread through a future
Stroustrup - Madrid'11 92
Concurrency: std::thread#include<thread>
void f() { std::cout << "Hello "; }
struct F {void operator()() { std::cout << "parallel world "; }
};
int main() {
std::thread t1{f}; // f() executes in separate threadstd::thread t2{F()}; // F()() executes in separate thread
} // spot the bugsStroustrup - Madrid'11 93
Concurrency: std::threadint main(){
std::thread t1{f}; // f() executes in separate threadstd::thread t2{F()}; // F()() executes in separate thread
t1.join(); // wait for t1t2.join(); // wait for t2
}
// and another bug: don’t write to cout without synchronization
Stroustrup - Madrid'11 94
Thread – pass arguments• Use function object or bind()
void f(vector<double>&);struct F {
vector<double>& v;F(vector<double>& vv) :v{vv} { }void operator()();
};
int main(){
std::thread t1{std::bind(f,some_vec)}; // f(some_vec)std::thread t2{F(some_vec)}; // F(some_vec)() t1.join(); t2.join();
} Stroustrup - Madrid'11 95
Thread – pass arguments• Use bind() or variadic constructor
void f(vector<double>&);struct F {
vector<double>& v;F(vector<double>& vv) :v{vv} { }void operator()();
};
int main(){
std::thread t1{std::bind(f,some_vec)}; // f(some_vec)std::thread t2{f,some_vec}; // f(some_vec) t1.join();t2.join();
}Stroustrup - Madrid'11 96
Thread – pass result (primitive)void f(vector<double>&, double* res); // place result in resstruct F {
vector& v; double* res;F(vector<double>& vv, double* p) :v{vv}, res{p} { } void operator()(); // place result in res
};
int main(){
double res1; double res2;std::thread t1{f,some_vec,&res1}; // f(some_vec,&res1)std::thread t2{F,some_vec,&res2}; // F(some_vec,&res2)()t1.join(); t2.join();std::cout << res1 << ' ' << res2 << '\n';
} Stroustrup - Madrid'11 97
Mutual exclusion: std::mutex• A mutex is a primitive object use for controlling access in a
multi-threaded system.• A mutex is a shared object (a resource)• Simplest use:
std::mutex m;int sh; // shared data// ...m.lock();// manipulate shared data:sh+=1;m.unlock();
Stroustrup - Madrid'11 99
Mutex – try_lock()
• Don’t wait unnecessarilystd::mutex m;int sh; // shared data// ...if (m.try_lock()) { // manipulate shared data:
sh+=1;m.unlock();
}else {
// maybe do something else}
Stroustrup - Madrid'11 100
Mutex – try_lock_for()
• Don’t wait for too long:std::timed_mutex m;int sh; // shared data// ...if (m.try_lock_for(std::chrono::seconds(10))) { // Note: time
// manipulate shared data:sh+=1;m.unlock();
}else {
// we didn't get the mutex; do something else}
Stroustrup - Madrid'11 101
Mutex – try_lock_until()
• We can wait until a fixed time in the future:std::timed_mutex m;int sh; // shared data// ...if (m.try_lock_until(midnight)) { // manipulate shared data:
sh+=1; m.unlock();
}else {
// we didn't get the mutex; do something else}
Stroustrup - Madrid'11 102
Recursive mutex
• In some important use cases it is hard to avoid recursionstd::recursive_mutex m;int sh; // shared data// ...void f(int i) {
// ...m.lock(); // manipulate shared data:sh+=1; if (--i>0) f(i); m.unlock(); // ...
}Stroustrup - Madrid'11 103
RAII for mutexes: std::lock• A lock represents local ownership of a non-local resource
(the mutex) std::mutex m;int sh; // shared data
void f(){
// ...std::unique_lock lck(m); // grab (acquire) the mutex// manipulate shared data:sh+=1;
} // implicitly release the mutex
Stroustrup - Madrid'11 104
Lock (local)
mutex(shared over time)
Potential deadlock
• Unstructured use of multiple locks is hazardous:std::mutex m1;std::mutex m2;int sh1; // shared dataint sh2;// ...void f(){
// ... std::unique_lock lck1(m1);std::unique_lock lck2(m2);// manipulate shared data:sh1+=sh2;
}Stroustrup - Madrid'11 105
RAII for mutexes: std::lock• We can safely use several locks
void f(){
// ...std::unique_lock lck1(m1,std::defer_lock); // make locks but don't yet
// try to acquire the mutexesstd::unique_lock lck2(m2,std::defer_lock);std::unique_lock lck3(m3,std::defer_lock);// …lock(lck1,lck2,lck3);// manipulate shared data
} // implicitly release the mutexes
Stroustrup - Madrid'11 106
Future and promise
• future+promise provides a simple way of passing a value from one thread to another– No explicit synchronization– Exceptions can be transmitted between threads
Stroustrup - Madrid'11 107
future promise
result
get()set_value()
set_exception()
Future and promise• Get from a future<X> called f:
X v = f.get();// if necessary wait for the value to get
• Put to a promise<X> called p (attached to f):try {
X res;// compute a value for resp.set_value(res);
} catch (...) {// oops: couldn't compute resp.set_exception(std::current_exception());
}
Stroustrup - Madrid'11 108
Type-safe simple concurrencydouble accum(double* b, double* e, double init);
double comp(vector<double>& v) // spawn many tasks if v is large enough{
const auto vs = v.size();if (vs<10000) return accum(&v[0], &v[0]+vs ,0.0);
auto f0 = async(accum, &v[0], &v[vs/4], 0.0); // first quarterauto f1 = async(accum, &v[vs/4], &v[vs/2], 0.0); // second quarterauto f2 = async(accum, &v[vs/2], &v[vs*3/4], 0.0); // third quarterauto f3 = async(accum, &v[vs*3/4], &v[0]+vs, 0.0); // fourth quarter
return f0.get()+f1.get()+f2.get()+f3.get();}
Stroustrup Models Madrid'11 109
C++0x
Stroustrup - Madrid'11
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 builders110
Stroustrup - Madrid'11
More information• My home pages
– C++0x FAQ– Papers, FAQs, libraries, applications, compilers, …
• Search for “Bjarne” or “Stroustrup”• “What is C++0x ?” paper
• My HOPL-II and HOPL-III papers• The Design and Evolution of C++ (Addison Wesley 1994)• 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.– http://www.softwarepreservation.org/projects/c_plus_plus/– Search for “C++ Historical Sources Archive”
111