Trends and future of C++: Evolving a systems language for performance - by Bjarne Stroustrup

Post on 22-May-2015

17.769 views 1 download

Tags:

description

Bjarne Stroustrup presentation at Universidad Carlos III de Madrid, march 18 2011 on : - The design of C++0x - C++: Machine model and resource management

Transcript of Trends and future of C++: Evolving a systems language for performance - by Bjarne Stroustrup

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