C++20标准草案：2020-11-14版

需积分: 1 17 浏览量更新于2024-06-16 收藏 6.89MB PDF 举报

"ISO-IEC-14882-2020-C++Draft-2020-11-14" ISO/IEC 14882是C++编程语言的标准文档，其2020年版本是C++20标准的最新工作草案，发布于2020年11月14日，修订了N4849版本。尽管这是一份早期草案，可能存在不完整和错误，以及格式问题，但它为C++开发者提供了最新的语言规范。 C++20是C++语言的一个重要里程碑，引入了许多新特性以增强语言的效率、可读性和表达力。这份草案包含的内容广泛，涵盖从基础的语法约定到复杂的语言特性。 1. **范围**：标准定义了C++编程语言的各个方面，包括语法、语义、库和实现要求。 2. **规范引用**：标准可能引用了其他相关的技术规范，确保C++与这些规范兼容。 3. **术语和定义**：这部分定义了C++语言中的关键术语，是理解和解释标准其余部分的基础。 4. **一般原则**： - **实施合规**：讨论了编译器和其他工具如何符合C++20标准的要求。 - **文档结构**：介绍了标准文档的组织方式。 - **语法表示法**：规定了如何用BNF（巴科斯范式）或其他形式来描述C++的语法结构。 5. **词法约定**：这部分详细规定了C++源代码的构成，如分隔符、翻译阶段、字符集、预处理 token、替代token、关键字、操作符和标点符号、字面量等。 6. **基础**：涵盖了一些基本概念，如程序的预处理、声明和定义、一次定义规则、作用域、名字查找、程序和链接、内存和对象、类型、程序执行等。 6.1 **序言**：介绍标准的基本意图和目的。 6.2 **声明和定义**：描述了如何声明变量、函数等，并定义它们的作用。 6.3 **一次定义规则**：防止同一实体在程序的不同部分被多次定义。 6.4 **作用域**：规定了标识符的有效范围。 6.5 **名字查找**：阐述了如何找到标识符所引用的对象或函数。 6.6 **程序和链接**：涉及到程序的组成单元和不同模块之间的链接。 6.7 **内存和对象**：定义了对象的生命周期、存储和初始化。 6.8 **类型**：涵盖了C++中的类型系统，包括基本类型、复合类型、模板等。 6.9 **程序执行**：规定了程序的运行时行为。 C++20的具体新特性包括模块化（Modules）、协程（Coroutines）、Concepts（概念）、可选值（std::optional）、强类型枚举（Strongly-Typed Enums）、原子线程安全（Atomic Thread-Fence）、改进的Lambda表达式、并行算法扩展、新的数学函数和更多。这些新特性的引入旨在提高代码的可维护性、性能和并发能力。 ISO/IEC 14882-2020 C++ Draft 提供了C++20标准的详细规范，是开发者、教育者和编译器开发者理解C++语言的权威指南。

3.33 [defns.observer]

observer function

〈

library

〉

class member function that accesses the state of an object of the class but does not alter that state

[Note 1 to entry: Observer functions are speciﬁed as const member functions (11.4.3.2). — end note]

3.34 [defns.parameter]

parameter

〈

function or catch clause

〉

object or reference declared as part of a function declaration or deﬁnition or in the

catch clause of an exception handler that acquires a value on entry to the function or handler

3.35 [defns.parameter.macro]

parameter

〈

function-like macro

〉

identiﬁer from the comma-separated list bounded by the parentheses immediately

following the macro name

3.36 [defns.parameter.templ]

parameter

〈template〉 member of a template-parameter-list

3.37 [defns.prog.def.spec]

program-deﬁned specialization

〈

library

〉

explicit template specialization or partial specialization that is not part of the C

standard library

and not deﬁned by the implementation

3.38 [defns.prog.def.type]

program-deﬁned type

〈

library

〉

non-closure class type or enumeration type that is not part of the C

standard library and not

deﬁned by the implementation, or a closure type of a non-implementation-provided lambda expression, or an

instantiation of a program-deﬁned specialization

[Note 1 to entry: Types deﬁned by the implementation include extensions (4.1) and internal types used by the library.

— end note]

3.39 [defns.projection]

projection

〈library〉 transformation that an algorithm applies before inspecting the values of elements

[Example 1 :

std::pair<int, std::string_view> pairs[] = {{2, "foo"}, {1, "bar"}, {0, "baz"}};

std::ranges::sort(pairs, std::ranges::less{}, [](auto const& p) { return p.first; });

sorts the pairs in increasing order of their first members:

{{0, "baz"}, {1, "bar"}, {2, "foo"}}

— end example]

3.40 [defns.referenceable]

referenceable type

type that is either an object type, a function type that does not have cv-qualiﬁers or a ref-qualiﬁer, or a

reference type

[Note 1 to entry: The term describes a type to which a reference can be created, including reference types. — end

note]

3.41 [defns.replacement]

replacement function

〈library〉 non-reserved function whose deﬁnition is provided by a C

program

[Note 1 to entry: Only one deﬁnition for such a function is in eﬀect for the duration of the program’s execution, as

the result of creating the program (5.2) and resolving the deﬁnitions of all translation units (6.6). — end note]

3.42 [defns.repositional.stream]

repositional stream

〈library〉 stream that can seek to a position that was previously encountered

§ 3.42 6

3.43 [defns.required.behavior]

required behavior

〈

library

〉

description of replacement function and handler function semantics applicable to both the behavior

provided by the implementation and the behavior of any such function deﬁnition in the program

[Note 1 to entry: If such a function deﬁned in a C

program fails to meet the required behavior when it executes,

the behavior is undeﬁned. — end note]

3.44 [defns.reserved.function]

reserved function

〈library〉 function, speciﬁed as part of the C

standard library, that is deﬁned by the implementation

[Note 1 to entry: If a C

program provides a deﬁnition for any reserved function, the results are undeﬁned. — end

note]

3.45 [defns.signature]

signature

〈function〉 name, parameter-type-list, and enclosing namespace (if any)

[Note 1 to entry: Signatures are used as a basis for name mangling and linking. — end note]

3.46 [defns.signature.friend]

signature

〈

non-template friend function with trailing requires-clause

〉

name, parameter-type-list, enclosing class, and

trailing requires-clause

3.47 [defns.signature.templ]

signature

〈

function template

〉

name, parameter-type-list, enclosing namespace (if any), return type, template-head, and

trailing requires-clause (if any)

3.48 [defns.signature.templ.friend]

signature

〈

friend function template with constraint involving enclosing template parameters

〉

name, parameter-type-list,

return type, enclosing class, template-head, and trailing requires-clause (if any)

3.49 [defns.signature.spec]

signature

〈

function template specialization

〉

signature of the template of which it is a specialization and its template

arguments (whether explicitly speciﬁed or deduced)

3.50 [defns.signature.member]

signature

〈

class member function

〉

name, parameter-type-list, class of which the function is a member, cv-qualiﬁers (if

any), ref-qualiﬁer (if any), and trailing requires-clause (if any)

3.51 [defns.signature.member.templ]

signature

〈

class member function template

〉

name, parameter-type-list, class of which the function is a member, cv-

qualiﬁers (if any), ref-qualiﬁer (if any), return type (if any), template-head, and trailing requires-clause (if

any)

3.52 [defns.signature.member.spec]

signature

〈

class member function template specialization

〉

signature of the member function template of which it is a

specialization and its template arguments (whether explicitly speciﬁed or deduced)

3.53 [defns.stable]

stable algorithm

〈library〉 algorithm that preserves, as appropriate to the particular algorithm, the order of elements

[Note 1 to entry: Requirements for stable algorithms are given in 16.4.6.8. — end note]

§ 3.53 7

3.54 [defns.static.type]

static type

type of an expression resulting from analysis of the program without considering execution semantics

[Note 1 to entry: The static type of an expression depends only on the form of the program in which the expression

appears, and does not change while the program is executing. — end note]

3.55 [defns.traits]

traits class

〈

library

〉

class that encapsulates a set of types and functions necessary for class templates and function

templates to manipulate objects of types for which they are instantiated

3.56 [defns.unblock]

unblock

satisfy a condition that one or more blocked threads of execution are waiting for

3.57 [defns.undeﬁned]

undeﬁned behavior

behavior for which this document imposes no requirements

[Note 1 to entry: Undeﬁned behavior may be expected when this document omits any explicit deﬁnition of behavior

or when a program uses an erroneous construct or erroneous data. Permissible undeﬁned behavior ranges from

ignoring the situation completely with unpredictable results, to behaving during translation or program execution in

a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to

terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs

do not engender undeﬁned behavior; they are required to be diagnosed. Evaluation of a constant expression (7.7)

never exhibits behavior explicitly speciﬁed as undeﬁned in Clause 4 through Clause 15. — end note]

3.58 [defns.unspeciﬁed]

unspeciﬁed behavior

behavior, for a well-formed program construct and correct data, that depends on the implementation

[Note 1 to entry: The implementation is not required to document which behavior occurs. The range of possible

behaviors is usually delineated by this document. — end note]

3.59 [defns.valid]

valid but unspeciﬁed state

〈

library

〉

value of an object that is not speciﬁed except that the object’s invariants are met and operations on

the object behave as speciﬁed for its type

[Example 1 : If an object

of type

std::vector<int>

is in a valid but unspeciﬁed state,

x.empty()

can be called

unconditionally, and x.front() can be called only if x.empty() returns false. — end example]

3.60 [defns.well.formed]

well-formed program

program constructed according to the syntax rules, diagnosable semantic rules, and the one-deﬁnition

rule

§ 3.60 8

4 General principles [intro]

4.1 Implementation compliance [intro.compliance]

4.1.1 General [intro.compliance.general]

The set of diagnosable rules consists of all syntactic and semantic rules in this document except for those

rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in

“undeﬁned behavior”.

Although this document states only requirements on C

implementations, those requirements are often

easier to understand if they are phrased as requirements on programs, parts of programs, or execution of

programs. Such requirements have the following meaning:

—

(2.1)

If a program contains no violations of the rules in Clause 5 through Clause 32 and Annex D, a conforming

implementation shall, within its resource limits as described in Annex B, accept and correctly execute

that program.

—

(2.2)

If a program contains a violation of any diagnosable rule or an occurrence of a construct described in

this document as “conditionally-supported” when the implementation does not support that construct,

a conforming implementation shall issue at least one diagnostic message.

—

(2.3)

If a program contains a violation of a rule for which no diagnostic is required, this document places no

requirement on implementations with respect to that program.

[Note 1 : During template argument deduction and substitution, certain constructs that in other contexts require a

diagnostic are treated diﬀerently; see 13.10.3. — end note]

For classes and class templates, the library Clauses specify partial deﬁnitions. Private members (11.9) are not

speciﬁed, but each implementation shall supply them to complete the deﬁnitions according to the description

in the library Clauses.

For functions, function templates, objects, and values, the library Clauses specify declarations. Implementa-

tions shall supply deﬁnitions consistent with the descriptions in the library Clauses.

The names deﬁned in the library have namespace scope (9.8). A C

translation unit (5.2) obtains access to

these names by including the appropriate standard library header or importing the appropriate standard

library named header unit (16.4.3.2).

The templates, classes, functions, and objects in the library have external linkage (6.6). The implementation

provides deﬁnitions for standard library entities, as necessary, while combining translation units to form a

complete C

program (5.2).

Two kinds of implementations are deﬁned: a hosted implementation and a freestanding implementation. For a

hosted implementation, this document deﬁnes the set of available libraries. A freestanding implementation is

one in which execution may take place without the beneﬁt of an operating system, and has an implementation-

deﬁned set of libraries that includes certain language-support libraries (16.4.2.4).

A conforming implementation may have extensions (including additional library functions), provided they

do not alter the behavior of any well-formed program. Implementations are required to diagnose programs

that use such extensions that are ill-formed according to this document. Having done so, however, they can

compile and execute such programs.

Each implementation shall include documentation that identiﬁes all conditionally-supported constructs that

it does not support and deﬁnes all locale-speciﬁc characteristics.

5) “Correct execution” can include undeﬁned behavior, depending on the data being processed; see Clause 3 and 6.9.1.

6) This documentation also deﬁnes implementation-deﬁned behavior; see 4.1.2.

§ 4.1.1 9

4.1.2 Abstract machine [intro.abstract]

The semantic descriptions in this document deﬁne a parameterized nondeterministic abstract machine. This

document places no requirement on the structure of conforming implementations. In particular, they need

not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required

to emulate (only) the observable behavior of the abstract machine as explained below.

Certain aspects and operations of the abstract machine are described in this document as implementation-

deﬁned (for example,

sizeof(int)

). These constitute the parameters of the abstract machine. Each

implementation shall include documentation describing its characteristics and behavior in these respects.

Such documentation shall deﬁne the instance of the abstract machine that corresponds to that implementation

(referred to as the “corresponding instance” below).

Certain other aspects and operations of the abstract machine are described in this document as unspeciﬁed

(for example, order of evaluation of arguments in a function call (7.6.1.3)). Where possible, this document

deﬁnes a set of allowable behaviors. These deﬁne the nondeterministic aspects of the abstract machine. An

instance of the abstract machine can thus have more than one possible execution for a given program and a

given input.

Certain other operations are described in this document as undeﬁned (for example, the eﬀect of attempting

to modify a const object).

[Note 1: This document imposes no requirements on the behavior of programs that contain undeﬁned behavior.

— end note]

A conforming implementation executing a well-formed program shall produce the same observable behavior as

one of the possible executions of the corresponding instance of the abstract machine with the same program

and the same input. However, if any such execution contains an undeﬁned operation, this document places

no requirement on the implementation executing that program with that input (not even with regard to

operations preceding the ﬁrst undeﬁned operation).

The least requirements on a conforming implementation are:

—

(6.1)

Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine.

—

(6.2)

At program termination, all data written into ﬁles shall be identical to one of the possible results that

execution of the program according to the abstract semantics would have produced.

—

(6.3)

The input and output dynamics of interactive devices shall take place in such a fashion that prompting

output is actually delivered before a program waits for input. What constitutes an interactive device is

implementation-deﬁned.

These collectively are referred to as the observable behavior of the program.

[Note 2 : More stringent correspondences between abstract and actual semantics can be deﬁned by each implementation.

— end note]

4.2 Structure of this document [intro.structure]

Clause 5 through Clause 15 describe the C

programming language. That description includes detailed

syntactic speciﬁcations in a form described in 4.3. For convenience, Annex A repeats all such syntactic

speciﬁcations.

Clause 17 through Clause 32 and Annex D (the library clauses) describe the C

standard library. That

description includes detailed descriptions of the entities and macros that constitute the library, in a form

described in Clause 16.

Annex B recommends lower bounds on the capacity of conforming implementations.

Annex C summarizes the evolution of C

since its ﬁrst published description, and explains in detail the

diﬀerences between C

and C. Certain features of C

exist solely for compatibility purposes; Annex D

describes those features.

This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this

document as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable

behavior of the program. For instance, an actual implementation need not evaluate part of an expression if it can deduce that

its value is not used and that no side eﬀects aﬀecting the observable behavior of the program are produced.

8) This documentation also includes conditionally-supported constructs and locale-speciﬁc behavior. See 4.1.

§ 4.2 10

剩余1862页未读，继续阅读

ziyou

粉丝: 0
资源: 17

C++20标准草案：2020-11-14版

C++标准ISO14882

ISO IEC Standard 14882:2014, C++

ISO/IEC 14882 2014 Programming Languages C++

C++编程语言标准 - ISO/IEC FDIS 14882

ISO∕IEC 9899-working draft：n2596

ISO C++ Draft

C++ 0x Standard - Final Committee Draft

draft C++17 C++标准草案 英文版 PDF 非扫描版

ISO/IEC 9899:202x ,未来的C标准202X.pdf

2011-最终正式的C++11标准

最新资源

draft C++17 C++标准草案英文版 PDF 非扫描版