What – if anything – have we learned from C++?

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

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 Stroustrup - Lang.Next 2014

3. Overview • C++ • Context, aims, and early design decisions • Language myths • Social and technical points • Standardization, C compatibility, linking, … • Some key C++ design points • Generic programming • Resource management Stroustrup - Lang.Next 2014

4. Then – early 1980s • Ken and Dennis had only just proved that semi-portable systems programming could be done (almost completely) without assembler • C didn’t have function prototypes • “Lint” was the state of the art for static program analysis • Most computers were <1MB and <1MHz • PDP11s were cool • VT100s were state of the art • A “personal computer” about $3000 (pre-inflation $$$) • The IBM PC was still in the future • “Everybody” “knew” that “OO” was too slow, too special-purpose, and too difficult for ordinary mortals • “if you want a virtual function you cannot have done your analysis right” Stroustrup - Lang.Next 2014

5. The roots of C++ Domain-specific abstraction General-purpose abstraction Fortran Simula Java Cobol C++ C++11 C++14 Direct mapping to hardware C# Assembler BCPL C Stroustrup - Lang.Next 2014

6. C++ in two lines • What is C++? • Direct map to hardware • of instructions and fundamental data types • Initially from C • Zero-overhead abstraction • Classes with constructors and destructors, inheritance,generic programming, function objects • Initially from Simula • Much of the inspiration came from operating systems • What does C++ want to be when it grows up? • See above • And be better at it for more modern hardware and techniques Stroustrup - Lang.Next 2014

7. Map to Hardware • Primitive operations => instructions • +, %, ->, [], (), … • int, double, complex<double>, Date, … • vector, string, thread, Matrix, … • Objects can be composed by simple concatenation: • Arrays • Classes/structs • All maps to “raw memory” value handle value value handle value handle value value Stroustrup - Lang.Next 2014

8. Early Design Decisions (1979/80) • C compatibility • Almost: function declarations • Leave no room for a language below (except assembler) • Simula classes and class hierarchies • But all objects treated uniformly • e.g., class objects on the stackand integers in dynamic storage • Generic types and operations • Using macros • Yuck! • Constructors and destructors • Establishing invariants • Resource management • Concurrency support through libraries Stroustrup - Lang.Next 2014

9. Later (1980s) • Overloading (1983) • First: constructors, =, and functions • [], (), -> (. still missing) • Exceptions • Throw object catch by type • Use class hierarchies for grouping • Templates • Types and functions • Type and value parameters • Type deduction for template arguments • Implicit instantiation • Multiple inheritance • Especially useful for abstract classes (interfaces) Stroustrup - Lang.Next 2014

10. Control the Message Traditional (from 1985 onwards) and far too complex: • “C++ is a general-purpose programming language with a bias towards systems programming that • is a better C • supports data abstraction • supports object-oriented programming • supports generic programming” Stroustrup - Lang.Next 2014

11. Control the Message Conventional, simple, popular, and wrong: • “C++ is an Object-Oriented Language” • Implies (to many) • C++ is poorly designed • C compatibility is a mistake • Avoid most effective C++ techniques • Classes not in hierarchies • Non-virtual functions • Free-standing functions • Generic programming Stroustrup - Lang.Next 2014

12. Language Myths* • We want a simple language! • No, teachers want a simple language to teach • In a semester or a quarter • No, researchers want a simple language to manipulate • And extend • No, programmers what a simple language to start using • Developers want a comprehensive language to use • Languages grow over time (massively) • “Everybody” wants “a simpler language with just two more features” * Not all myths are believed by all people Not all myths are untrue everywhere Stroustrup - Lang.Next 2014

13. Language Myths • We want an intuitive notation! • People confuse the familiar for the simple • For new features, people insist on LOUD explicit syntax • For established features, people want terse notation • Examples: • template<typename Container> void sort(Container&); // early • void sort(Sortable& C); // later • try { f(x); } catch (Foo&) { … throw; } // early // plus exception specifications • f(x); // later • X* p = new X(2); // early (e.g., Simula) • X a(2); // later Stroustrup - Lang.Next 2014

14. Language Myths • We want an efficient language! • No, most of the time programmers want a convenient language • However slow • Most programmers can’t even measure performance • No, most researchers prefer an inefficient language • For which it is easy to devise optimizations and improvements • For many applications we need an efficient language • But not for most parts of most applications • Distributed fat can be expensive Stroustrup - Lang.Next 2014

15. Language Myths • We want a language for writing reliable code • No, many programmers are very intolerant about • Inconveniences imposed for reliability, performance, or security • The need to learn new concepts • No, most programmers do not care • They will ship when their management says “ship!” • Lack of professionalism Stroustrup - Lang.Next 2014

16. Language Myths • There is a best language • For everybody and for every task • One size fits all • Oh, no! • These myths confound • Education • Practice • Research • Language design • Management • Funding Stroustrup - Lang.Next 2014

17. Have a message • What is the language for? • Who is the language for? • What would make the language better? • Define “better” • Be specific • No language can be everything to everybody • C++ • Provides a direct map to hardware • Provides very general zero-overhead abstraction mechanisms • Primarily industrial • Rewards good programmers Stroustrup - Lang.Next 2014

18. Standardization • A necessary evil? • “You can’t have a major programming language controlled by a single company” • Actually, you can: Java, C#, … • There are many kinds of standardization • ISO, ECMA, IEEE, W3C, … • Long-term stability is a feature • You need a standards committee • Vendor neutral • Important for some major users • Deprives C++ or development funds Stroustrup - Lang.Next 2014

19. How is ISO C++ Standardization Done • 100 members at meetings, 200-300 more online • Primarily industry • Democratic process • one company one vote • No technical qualifications for membership ($1280/year) • the aim is consensus • Committees • add complexity (every feature can become a cancerous growth) • add delays • Have no coherent technical view • Ensure stability (a major feature) • Makes it hard to set and maintain direction • See “WG21” Stroustrup - Lang.Next 2014

20. C/C++ Compatibility An important feature and a massive problem Stroustrup - Lang.Next 2014

21. Compatibility • Compatibility • Is a feature • Stability over decades • Is valuable • Is expensive • is hard • Hard to correct mistakes • A (valid) alternative • Pascal • Turbo Pascal • Object Pascal • Pascal 2 • Ada • … • Modula • Modula2 • Modula3 • Oberon • Oberon-2 • Oberon-7 Stroustrup - Lang.Next 2014

22. Language Definition • How do you specify a language? • Not English! • Though compiler writers love it • Don’t define semantics of character sequences • At least go to ASTs • Not bottom-up lambda calculus • Not virtual machine • Formally describe key interfaces • Memory model • Concurrency model • Vector, List • Formally verify the implementation of those interfaces Stroustrup - Lang.Next 2014

23. Inter-language Interoperability • From day #1 • C linkage (and Fortran) • Interoperability was an explicit aim • No decent linkage • of C++-specific constructs • classes and templates • No C++-specific dynamic linkage • It takes two to tango • Interoperability is not just a C++ problem • A massive problem • Dragging C++ down to the C level (interfaces) • No standard-library types, no exceptions, … Stroustrup - Lang.Next 2014

24. Teaching - Massive Harm • “C fist” • Low-level hacking with lots of pointers, casts, and macros • “Pure OOP” • Deep class hierarchies with lots of virtual functions, pointers, casts, and macros • And more “use of a macro is a sign of a weakness in the design or in the language” Stroustrup - Lang.Next 2014

25. Community • The C++ user community has no real center • Not even the ISO C++ committee • Many benefit without contributing • An ISO standards committee has limited scope • A major failing • Somehow, I should have done better • Lots of “little empires” • platform, compiler, library, tool supplier, consultants • Some “little empires” are not so little N*100K users • Large corporations prefer languages they can own and control • No differential advantage in a shared, standardized language Stroustrup - Lang.Next 2014

26. Community • No owner • Hard to set and maintain direction • No Resources • Marketing • Libraries • Tool chains • No • “Universal” conference • Magazine • Web site • Library distribution point • 2013: The C++ Foundation Stroustrup - Lang.Next 2014

27. C++ • Language features exist to serve programming styles • Generic programming • Resource management Stroustrup - Lang.Next 2014

28. Generic Programming: Templates • 1980: Use macros to express generic types and functions • 1987 (and current) aims: • Extremely general/flexible • “must be able to do much more than I can imagine” • Zero-overhead • vector/Matrix/… to compete with C arrays • Well-specified interfaces • Implying overloading, good error messages, and maybe separate compilation • “two out of three ain’t bad” • But it isn’t really good either  • it has kept me concerned/working for 20+ years • Concepts! (now available) Stroustrup - Lang.Next 2014

29. Templates • A massive success in C++98, better in C++11, better still in C++14 • STL containers template<typename T> class vector { /* … */ }; • STL algorithms vector<int> v; // … sort(v.begin(),v.end()); • And much more • Compile-time duck typing • Leading to template metaprogramming Stroustrup - Lang.Next 2014

30. Algorithms and Function Objects • We parameterize • container type • element type • criteria, actions, and algorithms • Type and value parameters, • e.g. template<typename T, int N> class Buffer { … }; • Essential for flexibility and performance void g(vector< string>& vs) { auto p = find_if(vs.begin(), vs.end(), [](auto x) {x<"Griffin"}); // … } Stroustrup - Lang.Next 2014

31. C++14 Concepts • Duck typing isn’t good enough • We need better-specified interfaces to templates • State intent • Specify requirements for template arguments • A concept is a predicate on a set of types and values • For example template<typename Cont> requires Sortable<Cont>() // Sortable is a Sequence with random access void sort(Cont& container); Stroustrup - Lang.Next 2014

32. C++14 Concepts • Error handling is simple (and fast) template<Sortable Cont> // Sortable is a Sequence with random access void sort(Cont& container); vector<double> vec {1.2, 4.5, 0.5, -1.2}; list<int> lst {1, 3, 5, 4, 6, 8,2}; sort(vec); // 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 Stroustrup - Lang.Next 2014

33. 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 Stroustrup - Lang.Next 2014

34. Resources/Ownership • Garbage collection is neither necessary nor sufficient • This needs proof • Not necessary • I/we need to build many kinds of systems to prove that • Not sufficient • Non-memory resources • Thread-handles, file-handles, locks, sockets, containers holding non-memory resources • Resource retention time • Distributed systems • NUMA memory Stroustrup - Lang.Next 2014

35. Resources • A resource is something that must be acquired and later released • Explicitly or implicitly • Resource management should not be manual • We don’t want leaks • We don’t want complex resource management code • Pointer manipulation • Catch clauses • Dispose idiom • A resource should have an owner • Usually a “handle” • A “handle” should present a well-defined and useful abstraction handle Value Stroustrup - Lang.Next 2014

36. Resources • All C++ standard-library containers manage their elements • vector • list, forward_list(singly-linked list), … • map, unordered_map (hash table),… • set, multi_set, … • string • Other C++ standard-library classes manage other resources • Not just memory • thread, lock_guard, … • istream, fstream, … • unique_ptr, shared_ptr handle Value Garbage collection is not sufficient Stroustrup - Lang.Next 2014

37. Control • We control object lifetime/life-cycle • Creation of objects: constructors • Destruction of objects: destructors • Copying of objects • Construction and assignment • from on scope to another • Movement of objects • Construction and assignment • from on scope to another • Access to representation • At no cost compared to low-level hand coding Stroustrup - Lang.Next 2014

38. Resource Management • Use constructors and a destructor template<typename T> class Vector { // vector of elements of type T Vector(initializer_list<T>); // acquire memory; initialize elements ~Vector(); // destroy elements; release memory // … private: T* elem; // pointer to elements int sz; // number of elements }; void fct() { Vector<double> vd {1, 1.618, 3.14, 2.99e8}; Vector<string> vs {"Strachey", "Richards", "Ritchie"}; // … } Stroustrup - Lang.Next 2014

39. Move Semantics • Return a Matrix Matrix operator+(const Matrix& a, const Matrix& b) { Matrix r; // copy a[i]+b[i] into r[i] for each i return r; } Matrix res = a+b; • Define move a constructor for Matrix • don’t copy; “steal the representation” r: res: …….. Stroustrup - Lang.Next 2014

40. Modern C++: C++11 • As ever, what matters is how features work in combination template<typename C, typename V> vector<Value_type<C>*> find_all(C& c, V v) // find all occurrences of v in c { vector<Value_type<C>*> res; for (auto& x : c) if (x==v) res.push_back(&x); return res; } string m {"Mary had a little lamb"}; for (const auto p : find_all(m,'a')) // p is a char* if (*p!='a') cerr<< "string bug!\n"; Stroustrup - Lang.Next 2014

41. Syntactic convergence? Python C++14 def mean(seq): n = 0.0 for x in seq: n += x return n / len(seq) auto mean(const Sequence& seq) { auto n = 0.0; for (x : seq) n += x; return n / seq.size(); }

42. We can simplify • def mean(seq): return sum(seq) / len(seq) • auto mean(const Sequence& seq) { return accumulate(seq,{}) / seq.size();} • Nil of the appropriate type (Value_type<Sequence>) Stroustrup - Lang.Next 2014

43. Challenges Stroustrup - Lang.Next 2014

44. Questions? C++: A light-weight abstractionprogramming language Practice type-richprogramming • Key strengths: • software infrastructure • resource-constrained applications Stroustrup - Lang.Next 2014

45. C++ Information • www.isocpp.org • The C++ Foundation’s website • Standards information, articles, user-group information • Bjarne Stroustrup • A Tour of C++: All of C++ in 180 pages • The C++ Programming Language (4thedition): 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