Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "What – if anything – have we learned from C++?"— Presentation transcript:

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

2 Abstract What is the essence of C++? Why did it succeed despite its well-understood flaws? What lessons - if any - can be applied to newer languages? Themes: Social and technical factors. Resource management. Generic programming. The importance of being inefficient. The importance of syntax. How (not) to specify a language. Standardization and compatibility. And no, I don't plan to condemn C++ - it is still the best language around for a lot of things, and getting better. It just isn't anywhere near perfect (even of its kind) or the best at everything - and was never claimed to be. 1 hour – slides – chatty delivery Stroustrup - Lang.Next 2014

3 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

4 Overview C++ Language myths Social and technical points
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

5 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

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

7 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

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

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

10 Later (1980s) Overloading (1983) Exceptions Templates
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

11 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

12 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

13 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

14 Language Myths We want an intuitive notation! Examples:
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

15 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

16 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

17 Language Myths There is a best language Oh, no!
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

18 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

19 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

20 How is ISO C++ Standardization Done
100 members at meetings, 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

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

22 Compatibility A (valid) alternative Modula Modula2 Oberon Oberon-2
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

23 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

24 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

25 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

26 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

27 Community No owner No Resources No 2013: The C++ Foundation
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

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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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 Access to representation At no cost compared to low-level hand coding Stroustrup - Lang.Next 2014

39 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

40 Move Semantics Return a Matrix Define move a constructor for 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

41 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

42 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(); }

43 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

44 Challenges Stroustrup - Lang.Next 2014

45 Questions? C++: A light-weight abstraction programming language
Key strengths: software infrastructure resource-constrained applications Practice type-rich programming Stroustrup - Lang.Next 2014

46 Stroustrup - Modern C++ - Cambridge'14
C++ Information The C++ Foundation’s website Standards information, articles, user-group information Bjarne Stroustrup A Tour of C++: All of C++ in 180 pages The C++ Programming Language (4th edition): All of C++ in 1,300 pages Programming: Principles and Practice using C++ (2nd edition) 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

47 Tool chains Analysis tools Stroustrup - Lang.Next 2014

48 Syntax Syntax matters immensely
Often in non-obvious ways The C declarator syntax is an experiment that failed And is much beloved We can certainly do much better than C++’s syntax But would anyone really care? Stroustrup - Lang.Next 2014

49 Notes Inertia Committee work Mistakes Direction
Encourage upgrade, 20 year old books and tools Committee work Mistakes Technical Social Direction “we want a small simple language” not really How (not) to specify a language How to get libraries What makes new features accepted? Distribution Community Resource management Standardization A necessary evil? ABI Packages Right problem, wrong solution Stroustrup - Lang.Next 2014

50 Then – early 80s Languages – mostly designed in the 1970s
Ada Algol* APL* Assembler Basic* C Cobol* Fortran* Jovial* Lisp ML Modula-2 Pascal PL/1* Prolog Simula* Smalltalk Snobol* * presented at HOPL1 in 1978 Stroustrup - Lang.Next 2014

Download ppt "What – if anything – have we learned from C++?"

Similar presentations

Ads by Google