Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "What – if anything – have we learned from C++? Bjarne Stroustrup Morgan Stanley, Columbia, TAMU www.stroustrup.com."— Presentation transcript:

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

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 – 20-30 slides – chatty delivery Stroustrup - Lang.Next 20142

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 20143

4 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 20144

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 20145

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

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 20147

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

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 20149

10 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 201410

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 201411

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 201412

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 201413

14 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 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 201414

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 201415

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 201416

17 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 201417

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 201418

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 201419

20 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 201420

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

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

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 201423

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 201424

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 201425

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 201426

27 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 201427

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

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 201429

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

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

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 requires Sortable () // Sortable is a Sequence with random access void sort(Cont& container); Stroustrup - Lang.Next 201432

33 C++14 Concepts Error handling is simple (and fast) template // Sortable is a Sequence with random access void sort(Cont& container); vector vec {1.2, 4.5, 0.5, -1.2}; list 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 ’ does not satisfy the constraint ‘Sortable’ Additional information upon request Stroustrup - Lang.Next 201433

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 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 201434

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 201435

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 Stroustrup - Lang.Next 201436 handle Value

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 Stroustrup - Lang.Next 201437 handle Value Garbage collection is not sufficient

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 Construction and assignment from on scope to another – Access to representation At no cost compared to low-level hand coding Stroustrup - Lang.Next 201438

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

40 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” …….. res: r: Stroustrup - Lang.Next 201440

41 Modern C++: C++11 As ever, what matters is how features work in combination template vector *> find_all(C& c, V v) // find all occurrences of v in c { vector *> 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 201441

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) Stroustrup - Lang.Next 201443 auto mean(const Sequence& seq) { return accumulate(seq,{}) / seq.size(); } Nil of the appropriate type (Value_type )

44 Challenges Stroustrup - Lang.Next 201444

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

46 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 (4 th edition): All of C++ in 1,300 pages – Programming: Principles and Practice using C++ (2 nd edition) – www.stroustrup.com: Publication list, C++ libraries, FAQs, etc. www.stroustrup.com 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'1446

47 Tool chains Analysis tools Stroustrup - Lang.Next 201447

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 201448

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

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 201450


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

Similar presentations


Ads by Google