The ISO Standardization of C++ Bjarne Stroustrup · C++ ISO Standardization • Slow, bureaucratic,...

The ISO Standardization of

C++ Bjarne Stroustrup Texas A&M University

Princeton CITP visitor http://www.research.att.com/~bs

Overview • C++ • ISO Standardization • Case Study: Initialization

Stroustrup - CITP'11 3

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 continue


Programming Languages

Assembler

Cobol

Fortran

C++

C

Simula

C++98

General-purpose abstraction

Domain-specific abstraction

Direct mapping to hardware

Java

C# BCPL

C++11


C++ applications


C++ Applications

• www.research.att.com/~bs/applications.html


C++ Applications

www.lextrait.com/vincent/implementations.html


What is C++?

A multi-paradigm programming language

It’s C!

A hybrid language

An object-oriented programming language

Template meta-programming!

A random collection of features

Embedded systems programming language

Low level!

Buffer overflows

Too big!

Supports generic programming


C++ Key strength:

Building software infrastructure and resource-constrained applications

A light-weight-abstraction programming language


Timeline 1 • 1980 “C with Classes”

– Function declarations, classes, class hierarchies, public/private, constructors and destructors

– Task, random numbers • 1984 Named C++

– Overloading, virtual functions, inline, const – I/O streams, complex, generic

• 1985 Commercial release – Non-commercial source license: $75

• 1987 Release 2.0 – Type-safe linkage, multiple-inheritance

• 1989 ARM C++ – templates, exceptions

• 1990 ANSI standardization starts • 1991 ISO standardization starts

– Joint standards process Stroustrup - CITP'11 11

Timeline 2 • 1998 ISO standard

– RTTI, namespaces, export, bool, new casts, many template extensions, exception specifications etc.

– String, STL • 2003 ISO standard revision

– Bug fix release • 2003 Library TR

– Hash tables, regex, resource management pointers, etc. • 2006 Performance TR • 2011 ISO Standard 2011 (“C++0x”)

– Auto, static assert, uniform initialization, move semantic, lambda expressions, machine model, template aliases, variadic templates, constexpr, etc.

– Not “concepts” – Remove “export” and exception specifications – Threads, locks, etc.


Why is C++ Popular? • Reasons

– Abstraction plus efficiency • Zero-overhead abstraction • Direct mapping to hardware

– C compatibility • Low cost of entry

• Popular non-reasons – Just C compatibility – Just luck – First to market

• Except for Ada, Eiffel, Lisp (and Loops), Modula-2, Objective C, Smalltalk

– Marketing might – Free


Why standardize?

• Portability – Fear of dialects – Fear of imprecise specification – Fear of incomplete specification

• Control – No individual can be trusted – No company can be trusted – Nobody had a viable idea for a “consortium”

• Non aims – “every program runs identically everywhere” – “every compiled program is correct/safe”


Why ISO Standardization? • That’s what C did (i.e. “accepted/expected in the community”)

– And Fortran, Pascal, Ada, … • ISO standardization was/is the “gold standard of standards” • Hewett-Packard, IBM, and Sun demanded it


Why ISO Standardization?

• Alternatives – Commercial ownership – IEEE standardization – ECMA standardization – A “consortium” – “benevolent dictator for life”


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


Who standardizes? • Austria • Australia • Canada • Denmark • France • Germany • Ireland • Japan • The Netherlands • New Zealand • Norway • Russia • Spain • Sweden • Switzerland • UK • US

• Adobe • Apple • Amadeus • AT&T • Bloomberg • Borland • Cisco • Ericsson • DRW Holdings • Fujitsu • Google • Hewett-Packard • IBM • INRIA • Intel • Microsoft • Oracle • Red hat • SAP • Siemens • Sun • Symantec • …

• Boost Pro • CERN • CMU SEI • Dinkumware • Dynasim • Edison Design Group • Fermilab • Gimpel Software • HSR Rapperswil, CH • Indiana U. • Perennial • Plum Hall • Texas A&M U. • U. of Dresden • U. Carlos III, Madrid • Vollman Engineering • … • Many individuals (dozens)

• PhD (CS) • PhD (non-CS) • Masters (a few) • Bachelors • Unknown (the majority)

• Developers

– Compilers – Libraries – Tools – Applications

• Testers • Consultants

– Who writes code

• Small-business men – Who writes code


ISO C++ Standardization • Themes

– C/C++ compatibility – Innovation vs. existing practice – Library components vs. language features – Changes in standards process

• Process – Volunteers / no reward structure – Meetings

• 2 or 3 a year

– Working groups • Core, Library, Evolution plus “spin-off WGs”, e.g. concurrency

– Reflectors – Documents

• “mailings” Stroustrup - CITP'11 19

Standardization – why do people bother?

• Directly affects millions – Huge potential for improvement of application code

• There are still many new techniques to get into use – Standard support needed for mainstream use

• Defense against vendor lock-in – Only a partial defense, of course

• For C++, the ISO standards process is central – C++ has no rich owner who dictates changes, pays for design group, etc.

• And pays for marketing (instead, “rent out Bjarne” ) – The C++ standards committee is the central forum of the C++ community

• The members are volunteers with “day jobs” – For (too) many: “if it isn’t in the standard it doesn’t exist”

• Unfair, but a reality • i.e.: Mostly idealism Stroustrup - CITP'11 20

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


Problems – Tensions • C/C++ compatibility • The cult of the corner case

– Most people care about particular parts of the language/library – Few people have a global view

• Invariants vs. algorithms – List of cases

• The cult of the holy text – High priests of a low art

• Lack of resources – For experimentation, library building, testing


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)


The (real) problems • Help people to write better programs

– Easier to write – Easier to maintain – Easier to achieve acceptable resource usage

• Allow people to express fundamental ideas

– Directly – Without loss of efficiency

(compared to low-level techniques)


Problems for a revision • C++ is immensely popular

– over 3 million programmers according to IDC • But very hard to count accurately

– incredibly diverse user population • Application areas (http://www.research.att.com/~bs/applications.html) • Programmer ability

• Many people want improvements (of course) – See long “wish lists” on my C++ page

• For people like them doing work like them • “just like language XYZ” • And DON’T increase the size of the language, it’s too big already

• Many people absolutely need stability – Billions of lines of code

• Even good extensions can do harm – Performance – Learning effort (language size)


Something scary (from 2006)

• A torrent of language proposals – 14 proposals approved – 14 proposals “approved in principle” – 18 proposals “active in evolution group” – 43 proposals rejected or lingering – 64 Suggestions (not listed above) in my email in 2006 alone

• Observations – Many proposals are small – Many proposals are good (i.e. will/would make life easier for a largish group of people) – Few are downright silly – The standard will grow significantly – Textbooks will grow significantly – People will complain even more about complexity – People will complain about lack of new/obvious/great/essential features – We (the evolution working group and the committee as a whole) will make some mistakes – Doing nothing or very little would have been a much bigger mistake

• I’m still an optimist – C++0x will be a better tool than C++98 – much better


Something scary (from 2006)

• A lesser torrent of library proposals – 11 Components from Library TR1 (not yet special math functions) – 2 New component (Threads and thread pools) – Use of C++0x language features

• Rvalue initializers, variadic templates, general constant expressions, list constructors

• Observations – I very much would have liked to see more library components

• No GUI, XML, SQL, fine-grain concurrency • Commercial and open source opportunities

– On average a library facility is “bigger” than a language feature • Size of specification and Impact

• I’m still an optimist – C++0x will be a better tool than C++98 – much better – Library TR2 is being prepared

• File system manipulation, Date and time, Networking (sockets, TCP, UDP, iostreams across the net, etc.), Numeric_cast, …

– The library wish list has 50+ suggestions Stroustrup - CITP'11 27

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


Areas of language change • Machine model and concurrency

– Model – Threads library – Atomic ABI – Thread-local storage – Thread pools, futures

• Modules and dynamically linked libraries – Modules postponed for a TR

• Support for generic programming – concepts – uniform initialization – auto, decltype, template aliases, move semantics, …

• Etc. – static_assert – improved enums – long long, C99 character types, etc. – … Stroustrup - CITP'11 29

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


Problem #1: irregularity • There are four notations and none can be used everywhere

int a = 2; // “assignment style” int[] aa = { 2, 3 }; // assignment style with list complex z(1,2); // “functional style” initialization x = Ptr(y); // “functional style” for conversion/cast/construction

• Sometimes, the syntax is inconsistent/confusing int a(1); // variable definition int b(); // function declaration int b(foo); // variable definition or function declaration

• We can’t use initializer lists except in a few cases string a[] = { "foo", " bar" }; // ok: initialize array variable vector<string> v = { "foo", " bar" }; // error: initialize vector variable void f(string a[]); f( { "foo", " bar" } ); // error: initializer array argument Stroustrup - CITP'11 31

Is irregularity a real problem? • Yes, a major source of confusion and bugs • Can it be solved by restriction?

– No existing syntax can be used in all cases int a [] = { 1,2,3 }; // can’t use () here complex<double> z(1,2); // can’t use { } here struct S { double x,y; } s = {1,2}; // can’t use ( ) here int* p = new int(4); // can’t use { } or = here

– No existing syntax has the same semantics in all cases typedef char* Pchar; Pchar p(7); // error (good!) Pchar p = Pchar(7); // “legal” (ouch!)

• Principle violated: – Uniform support for types (user-defined and built-in)


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.2); v.push_back(2.3); v.push_back(3.4);

• Principle violated: – Support fundamental notions directly (“state intent”)


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, 2.3, 3.4 }; // bug vector<double> v(a, a+sizeof(a)/sizeof(int)); // hazard

• Principle violated: – Support user-defined and built-in types equally well


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" };


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);


Uniform initialization syntax • Every form of initialization can accept the { … } syntax

X x1 = X{1,2}; X x2 = {1,2}; // the = is optional X 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 };


Uniform initialization semantics • X { a } constructs the same value in every context

– { } initialization gives the same result in all places where it is legal X x{a}; X* p = new X{a}; z = X{a}; // use as cast f({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 - CITP'11 38

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


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


References • My site:

– B. Stroustrup: What is C++0x?. CVu. Vol 21, Issues 4 and 5. 2009. – B. Stroustrup: Evolving a language in and for the real world: C++ 1991-2006.

ACM HOPL-III. June 2007. (incl. slides and videos). – B. Stroustrup: “New” Value Terminology.

http://www2.research.att.com/~bs/terminology.pdf. 2010. – Gregor, et al: Linguistic support for generic programming. OOPSLA06. – Gabriel Dos Reis and Bjarne Stroustrup: Specifying C++ Concepts. POPL06. – B. Stroustrup: A History of C++: 1979-1991. ACM History of Programming

Languages conference (HOPL-2). March 1993. – Last pre-standard 2011 draft standard – C++11 FAQ (formerly C++0x FAQ)

• WG21 site:

– All proposals – All reports


http://portal.acm.org/toc.cfm?id=1238844

Date post:	30-Oct-2019
Category:	Documents
Upload:	others
View:	26 times
Download:	0 times