C++的演变与繁荣：2006-2020的关键历程

需积分: 10 158 浏览量更新于2024-07-15 收藏 1.71MB PDF 举报

"这篇文档是Bjarne Stroustrup撰写的一篇关于C++在2006年至2020年间发展历程的文章，标题为‘在拥挤和变化的世界中茁壮成长 - C++ 2006–2020’。文章由Yannis Smaragdakis编辑，讨论了C++在这15年间如何作为一个历史悠久但不断进化的语言在激烈的竞争中保持活力。" C++，自20世纪70年代初引入C语言以来，已经在工业界广泛使用了20多年。这个期间，C++包含了自始至终未改变的部分，也有21世纪初引入的新特性。从2006年到2020年，C++开发者社区从约300万增长到约450万。在此期间，新的编程模型出现，硬件架构发展，新的应用领域获得了巨大的重要性，许多资金充足且专业营销的语言在争夺主导地位。尽管C++是一个没有强大商业支持的老语言，但在这个充满挑战的时期，它仍然能够蓬勃发展。文章主要关注了ISO C++标准在2011、2014、2017和2020年修订中的重大变化。虽然C++20标准中的标准库占据了大约3/4，但本文的主要焦点在于语言特性及其支持的编程技术。文章列出了大量的特性，记录了C++的发展历程。显著的特征包括模板元编程的增强、现代内存管理工具（如智能指针）、并发和并行处理的支持（例如std::thread和std::async）、以及对C++核心语言的改进，如右值引用、lambda表达式和自动类型推断（auto关键字）等。这些特性使得C++能够适应更复杂的软件工程需求，同时保持高效性能。此外，C++在这段时间内还引入了对现代硬件优化的特性，比如对向量化的支持，以及对现代多核处理器的并行编程接口。C++标准库也得到了极大的扩展，增加了如文件系统库、并发工具和算法库的增强，提供了更加丰富和强大的功能。总体而言，C++通过不断演进，适应了编程环境的变化，满足了开发者的各种需求，从而在竞争激烈的编程语言世界中保持了其重要地位。这篇文章深入探讨了C++如何通过引入创新特性和改进，继续成为开发者的重要选择。

70:16 Bjarne Stroustrup

By 2006, C++ was no longer new and exciting in industry, but spread over many industries.

Usage was ś and still is ś strong in the telecommunications industry where C++ was born. From

there, it had spread into the games (e.g., Unreal, PlayStation, Xbox, and Douglas Adams’ łSpaceship

Titanicž), nance (e.g., Morgan Stanley and Renaissance Technologies), microelectronics (e.g., Intel

and Mentor Graphics), movies (e.g., Pixar and Maya), aerospace (e.g., Lockheed-Martin and NASA),

and many other industries.

Personally, I was particularly fond of C++’s widespread use in science and engineering, such as

High Energy Physics (e.g., CERN, SLAC, FermiLab), biology (e.g., the human genome project), space

exploration (e.g., Mars Rovers and the deep space communication network), medicine and biology

(e.g., tomography, general imaging, the human genome project, and monitoring equipment), and

much more.

2.4 Other Languages

People often look for direct technical inuences from other programming languages on C++. There

are few. Typically, inuences bubble up through history from common ancestors and shared ideas.

Decisive arguments for extending C++ tend to relate to observed problems in the C++ community.

Direct borrowing from a fashionable language is rare and far more dicult than people imagine.

Most members of the standards committee master many languages and keep an eye out for useful

facilities, libraries, and techniques.

Consider some real and conjectured inuences on C++ in the 2000s:

• auto

ś the ability to deduce a type from an initializer. This is popular in modern languages,

but old as the mountains. I don’t really know where it came from, but I implemented it in

1983 and didn’t consider it novel then (ğ4.2.1).

• tuple

ś many languages, especially from the functional programming tradition have tuples,

usually as a built-in type. The C++ standard-library

tuple

and many of its uses are inspired

from those. The std::tuple was derived from the boost::tuple [Boost 1998ś2020] (ğ4.3.4).

• regex

ś The standard library

regex

added in C++11 was copied (via Boost with proper

acknowledgements) from facilities in Unix and JavaScript (ğ4.6).

•

Functional programming ś there are many obvious similarities between FP features and C++

constructs. Most are not simple language features, but programming techniques. The STL

was inspired by functional programming and rst tried (unsuccessfully) in Scheme [Stepanov

1986] and Ada [Musser and Stepanov 1987].

• future and promise ś from Multilisp via other Lisp dialects (ğ

4.1.3).

•

Range-

for

ś it has equivalents in many languages, but one direct inspiration was STL

sequences (ğ4.2.2).

• variant, any, and optional ś clearly inspired by a variety of languages (ğ

8.3).

•

Lambdas ś clearly the use of lambda expressions in functional languages was part of the

inspiration. However, in C++, the roots of lambdas also include blocks of code used as

expressions going back to BCPL, local functions (which had been repeatedly rejected for C and

C++ because they were seen as error-prone and adding complexity), and (most importantly)

function objects (ğ4.3.1).

• nal

and

override

ś for more explicit management of class hierarchies and present in many

object-oriented languages. They had been considered ś and considered unnecessary ś from

the earliest days of C++.

•

The three-way comparison operator,

<=>

, was inspired by C’s

strcmp

and op erators in

various languages, including PERL, PHP, Python, and Ruby (ğ9.3.4).

Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 70. Publication date: June 2020.

Thriving in a Crowded and Changing World: C++ 2006ś2020 70:17

• await

ś the original C++ coroutines (ğ1.1) were inspired by uses of Simula, but oered as

a library rather than as a language feature to leave room for several alternative ways of

expressing concurrency. The idea for the C++20 stackless coroutines came primarily from F#

(ğ9.3.2).

Even when a feature is borrowed from another language in a pretty direct manner, it mutates.

Typically, the syntax changes quite a bit to t into C++. When borrowing from a garbage-collected

language, lifetime issues must be dealt with, and often the C++ distinction between objects and

references to objects needs to b e addressed in ways that dier from the original. Often novel uses

are discovered during the łtranslationž into C++. The story of the introduction of łlambdasž into

C++ oers examples of most of these phenomena (ğ4.3.1).

Many people imagine that I (and others involved with C++) sit around all day strategizing in a

complicated war for dominance among popular languages. In fact, I spend no time on such. Most

days, I don’t think ab out other languages except when I happen to study one out of general te chnical

interest or use one to get some work done. What I do is to talk with software developers, consider

problems that people encounter using C++, and consider the ood of suggested improvements in

the standards committee. Of course, I also write code to experience problems and test out ideas

for improvements. The problem is to nd time to calmly consider what’s fundamental, what’s just

fashion, and what would do harm.

Similarly, C++’s contributions to other languages are hard to pinpoint. Often, similar features

are parallel evolution or have common roots. Consider:

•

Generics in Java and C# ś they modeled their generics from other languages but took the C++

syntax and added generics only after C++ demonstrated the utility of generic programming

on a large scale.

•

The dispose idiom in Java, Python, etc. ś that is about the best you can do to approximate

destructors in a garbage-collected language.

•

Compile time evaluation in the D programming language ś I explained the early

constexpr

design to Walter Bright.

•

C++’s model of object lifetime based on constructors and destructors was part of the inspira-

tion for Rust. Amusingly, these days, C++ is often accused of having borrowed such ideas

from Rust.

•

C adopted the C++11 memory model, the function declaration and denition syntax, declara-

tions as statements, const, //-comments, inline, and initializers in for-loops.

Many dierences between C++ and other languages stem from C++’s use of destructors. That

makes it hard for garbage-collected languages to borrow directly from C++.

3 THE C++ STANDARDS COMMITTEE

The international C++ standards committee, ocially named ISO/IEC JTC1/SC22/WG21, is central

to the development of C++. This has been the case since its founding in 1991 and before that the

focus of C++ development was the ANSI C++ standards committee from 1989 [Stroustrup 1993].

C++ has no rich owner or other signicant funding sources, so the community relies on corporate

development and open-source projects. WG21 and the National Standards committees are the only

venues where people from otherwise competing organizations can meet to jointly solve problems.

The members are all volunteers ś there is no paid secretariat ś even if many members do come as

representatives of the organizations they work for. At every meeting, there are people who proudly

claim to represent łself.ž That is, they are not sponsored and represent only themselves. It is not

uncommon for someone turning up to represent a new organization after a job change. There are

many examples of people making łattendance of the C++ standards committeež as a condition for

Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 70. Publication date: June 2020.

70:18 Bjarne Stroustrup

accepting a new job. People have joined the committee to learn about C++ and łmember of the C++

committeež has been quoted as a qualication (not always truthfully).

Some participate only for a couple of meetings or infrequently. On the other hand, there are

people who have been at most meetings over decades. In the beginning and currently, there are three

meetings a year. During a few years after the 1998 standard, we met only twice a year. Currently,

the face-to-face meetings are supplemented with several teleconferences and many, many emails

every day.

Here, I describe

• The role of the standard (ğ

3.1)

• The organization of the committee (ğ

3.2)

• The impact of the committee structure on the design of C++ (ğ

3.3)

3.1 The Standard

The purpose of the standards committee is to write a standard. One ocial rationale for standards

is łfacilitating trade, particularly in reducing technical barriers and articial obstacles to international

tradež and łproviding a framework for achieving economies, eciencies and interoperability.ž A stan-

dard is a sp ecication, not an implementation. Its purpose is to keep multiple implementations in

agreement, and to decide exactly what łagreementž means in a world where diverse underlying

hardware must be exploited eectively. Many programmers have a problem understanding that.

They consider their current compiler the denition of the language or have trouble understanding

why it is hard to get 100% agreement among many separate ś and typically competing ś orga-

nizations. In the 1990s, the committee considered formal specication but after consulting with

world-class experts concluded that neither specication technology nor the committee members

were up to a formal specication of C++. Obviously, the idea of a reference implementation was

considered, but the complexity of the language and especially issues related to hardware use and

optimization have defeated such ideas. It would be too complicated and too expensive. Alterna-

tively, it would be simplied to the point where it couldn’t help with the hardest problems where it

would be most needed. Also, a complicated reference implementation would be as likely to hide

surprises as N competing implementation teams documenting their decisions, running extensive

conformance tests, and discussing where they dier. For C++, N is at least four when it comes to

front-ends (Clang, EDG, GCC, and Microsoft) and at least a dozen for backends.

So, the standards committee is grappling with the problems of having many implementations.

The alternative would be to take the risks of a monoculture. If a single organization was the source

of C++ technology, everybody would get the same, for good and bad. An organization controlling

the łone true implementationž would have a dominant voice in the community and problems

there would aect all. In particular, funding problems, commercial concerns, political opinions, and

technical single-mindedness could seriously damage the language and its community.

For good and bad, the C++ community chose the semi-organized chaos of a large committee

plus multiple compiler, tools, and library suppliers over a unied ownership/dictatorship model.

3.2 Organization

For the work on C++17 and C++20, as many as 250 people turned up at each face-to-face WG21

meeting, out of a membership of about twice that. In addition, there are national standards commit-

tees and C++ standards interest groups supporting members in a dozen or more countries, including

Canada, Finland, France, Germany, Russia, Spain, the UK, and the USA. The members represent

more than a hundred organizations. To give an idea, here is a selection: Apple, Bloomberg, CERN,

Codeplay, EDG (Edison Design Group), Facebook, Google, IBM, Intel, Microsoft, Morgan Stanley,

Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 70. Publication date: June 2020.

Thriving in a Crowded and Changing World: C++ 2006ś2020 70:19

Nvidia, Qt, Qualcom, Re d Hat, Ripple, Sandia National Labs, University of Applied Sciences HSR

Rapperswil, and University of Carlos III, Madrid. There is a solid representation from compiler

suppliers, hardware suppliers, nance, games, library providers, platform suppliers, national labs

(physics), and more. The telecom presence that was prominent in early C++ has decreased, whereas

university presence, which used to be minimal, seems to be on the increase.

Obviously, such a large group of organizations and individuals, representing widely varying

interest and technical backgrounds, need an organizational structure to function. The me etings are

organized around working groups (WGs) and study groups (SGs). In the summer of 2019, we had:

•

Core WG (CWG) ś writes the nal standards text for the language ś chair, Michael Miller

(EDG).

•

Library WG (LWG) ś writes the nal standards text for the standard library ś chair, Marshall

Clow (The C++ Alliance, formerly Qualcom).

•

Evolution WG (EWG) ś processes language proposals ś chair, Ville Voutilainen (Qt, formerly

Symbio).

•

Library Evolution WG (LEWG) ś processes standard-library proposals ś chair, Titus Winters

(Google).

Study groups explore new areas and designs for possible standardization:

• SG1, Concurrency ś concurrency and parallelism topics ś chair, Olivier Giroux (Nvidia).

•

SG5, Transactional Memory ś Exploring transactional memory constructs ś chair, Michael

Wong (Codeplay, formerly IBM).

•

SG6, Numerics ś including but not limited to xed point, decimal oating point, and fractions

ś chair, Lawrence Crowl ("self," formerly Google and Sun).

•

SG7, Compile-time programming ś Initially focused on compile-time reection, then expanded

to compile-time programming in general ś chair, Chandler Carruth (Google).

•

SG12, Undened behavior and Vulnerabilities ś a systematic review of vulnerabilities and

undened/unspecied behavior ś chair, Gabriel Dos Reis (Microsoft, formerly Texas A&M

University).

•

SG13, Human/Machine Interface and I/O ś selected low-level output (e.g., graphics, audio) and

input (e.g., keyb oard, pointing) I/O primitives ś chair, Roger Orr (British Standards (BSI)).

•

SG14, Game Development and Low Latency ś topics of interest to game developers and others

with low-latency requirements ś chair, Michael Wong (Codeplay, formerly IBM).

•

SG15, Tooling ś topics related to creation of developer tools for standard C++, including but

not limited to modules and package management ś chair, Titus Winters (Google).

•

SG16, Unicode ś topics related to Unicode text processing in C++ ś chair, Tom Honermann

(Synopsis).

• SG19, Machine Learning ś chair, Michael Wong (CodePlay, formerly IBM)

•

SG20, Education ś looking for ways to support learners and teachers approach C++ as it is

today ś chair, Jan Christiaan van Winkel (Google)

•

SG21, Contracts ś trying to design a contact system after the failure to do so for C++20 (ğ9.6.1)

ś chair John Spicer (EDG).

In 2017, a small group was established to address problems to do with the lack of direction in

the design of the language and standard library [Dawes et al

2018]. The members of this Direction

Group (DG) are appointed by the convener in consultation with the WG chairs. Its members are

long-term contributors to the committee, language, and standard library. The initial members were

Beman Dawes, Howard Hinnant, Bjarne Stroustrup, David Vandevoorde, and Michael Wong; later,

Beeman retired and Roger Orr joined). The DG chairmanship is rotating, starting with me. The DG

Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 70. Publication date: June 2020.

70:20 Bjarne Stroustrup

is advisory and has the policy of only giving opinions when its members agree unanimously. It

maintains a document presenting its recommendations [Dawes et al. 2018; Hinnant et al. 2019]

The WGs p ersist over decades with slowly changing membership. The SGs come and go as interest

dictates and/or they complete their work and hand over proposals to WGs for nal processing. For

example, four of the most signicant SGs have declared victor y and disbanded:

• SG2, Modules ś chair, Gabriel Dos Reis (Microsoft, formerly Texas A&M University).

• SG3, File system ś chair, Beman Dawes ("self").

•

SG8, Concepts ś chair, Andrew Sutton (University of Akron, Ohio, formerly Texas A&M

University).

•

SG9, Ranges ś updating the STL to use concepts, simplify notation, and provide innite

sequences and pipelining ś chair, Eric Niebler (FaceBook).

SG4, Networking is dormant as its results are waiting to be merged into the standard (ğ8.8.1).

Another SG, SG11, databases, disbanded for lack of consensus and lack of critical mass of volunteers

to get the work done.

Some SGs produce Technical Specications (TSs) that can be signicant documents in the style

of the standard itself. They have some ocial (ISO) standing but don’t oer the long-term stability

of an international standard (IS). The Concurrency SG (SG1) has been active since 2006, headed

by Hans-J Boehm (Google, formerly HP Labs, formerly SGI) for most of its existence, and has a

standing very similar to the WGs.

In addition to these groups, there is a semi-ocial C/C++ liaison group consisting of people who

are members of both the C++ committee and the C committee (ISO/SC22/WG14). This group tries

to minimize C/C++ incompatibilities and the C++ standard documents every incompatibility. C

and C++ are far more compatible than they would have been without the constant eort of the

liaison group, but even then, most of the many features imported into C from C++ were modied

so that they introduce d some incompatibility.

There are just three ocial ocers required by and recognized by the ISO:

•

Convener ś chairs the WG, sets the WG meeting schedule (łconvenesž meetings), appoints

Study Groups, and is responsible to higher levels of ISO (SC22, JTC1, and ITTF) for the WG’s

work ś Herb Sutter (Microsoft) who has held that position since 2002 with a break from

2008-2009 when PJ. Plauger (Dinkumware) held it.

•

Project Editor ś ultimately responsible for applying committee-approved changes to the

standard’s working draft ś Richard Smith (Google); for C++11, Pete Becker (Dinkumware);

for C++14, Stephanus Du Toit (Intel).

•

Secretary ś responsible for taking and distributing minutes of WG21 meetings ś Nina Ranns

(Edison Design Group, formerly Symantec).

The National standards committe es have their own ocers and procedures.

Obviously, the positions are held by various people over the years, but it is rare for someone to

hold a position for less than 5 years, despite the typically heavy workload. I was chair of the EWG

for 24 years before handing over to Ville Voutilainen in 2014.

In general, smaller proposals go directly to EWG and/or LEWG and larger proposals start out in

a SG. Proposals need to come in writing and be presented by someone. Typically, processing of

a signicant proposal takes several meetings (often years) and requires several papers, revisions

of papers, and repeated presentations. Finally, a proposal that has gained strong support will be

presented to the committee as a whole for a nal vote. The convener looks at the vote and makes the

call whether there is consensus. Consensus is not just a majority. The committee prefers unanimity

after the WG processing and votes, and if that’s not the case, a 9:1 or 8:2 majority is usually required.

The convener may very well deem a 8:2 majority łnot consensus.ž This happens if heads of national

Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 70. Publication date: June 2020.

剩余167页未读，继续阅读

CodeArhat

粉丝: 13
资源: 55

C++的演变与繁荣：2006-2020的关键历程

Thriving in a Crowded and Changing World: C++ 2006–2020

Ford-Trends-Book-2016-Interactive.pdf

埃森哲-2021年技术愿景报告（英文）-2021.3-84页.pdf

天猫&贝恩-新零售下品牌消费者为中心的数字化转型-2019.3-80页.pdf

thriving-park:ThrivingPark.com的Web应用程序

The State of AI 2019 - Divergence.pdf

331. 2020年投资管理展望报告.pdf

High.Value.IT.Consulting.12.Keys.to.a.Thriving.Practice

词汇课 J K.pdf

Node Cookbook, Second Edition.pdf

最新资源