C++11标准文档N3376：编程语言C++的工作草案

需积分: 31 95 浏览量更新于2024-07-27 收藏 4.85MB PDF 举报

"C++ 11的英文标准文档N3376，是C++编程语言的早期草案，包含了从范围、术语定义到程序执行、多线程等内容的详细规范。" C++ 11是C++编程语言的一个重要版本，引入了许多新特性并优化了语言标准。该文档N3376是这一版本的标准草案，虽然存在不完整和错误，但为开发者提供了深入理解C++ 11的关键信息。 1. **范围(Scope)**：这部分规定了C++ 11语言的应用范围，包括哪些部分是标准涵盖的，以及如何与其他编程语言标准相互作用。 2. **规范性引用(Normative references)**：列出影响C++ 11标准的其他技术文档，这些文档的条款在本标准中具有法律效力。 3. **术语和定义(Terms and definitions)**：定义了C++ 11中使用的专业术语，如类、对象、函数等，确保了语言规范的一致性。 4. **实现合规性(Implementation compliance)**：解释了符合C++ 11标准的编译器和库应满足的要求，包括最小功能集和行为一致性。 5. **国际标准的结构(Structure of this International Standard)**：描述了标准文档的组织结构，方便读者查找和理解各个部分。 6. **语法记号(Syntax notation)**：定义了用于表示C++ 11语法的记号系统，如BNF（巴科斯范式）规则。 7. **C++内存模型(The C++ memory model)**：阐述了C++程序中数据存储、访问和同步的抽象模型，是理解并发和多线程的基础。 8. **C++对象模型(The C++ object model)**：详细介绍了C++中的类型系统和对象生命周期，包括构造、析构、继承和动态绑定。 9. **程序执行(Program execution)**：定义了程序从开始到结束的执行过程，包括控制流、异常处理和程序终止。 10. **多线程执行(Multi-threaded executions and data races)**：介绍了C++ 11新增的多线程支持，包括线程创建、同步原语和数据竞争的定义。 11. **致谢(Acknowledgments)**：对参与标准制定工作的个人和组织表示感谢。 12. **词法约定(Lexical conventions)**：这部分详细规定了C++源代码的基本构成单元，如字符集、预处理、标识符、关键字、操作符和字面量等。 13. **预处理(Preprocessing)**：涵盖预处理器的运作，包括宏替换、条件编译和头文件包含。 14. **标识符(Identiifiers)**：定义了合法的标识符规则，包括保留字和用户自定义标识符。 15. **关键词(Keywords)**：列出了C++ 11的所有关键字，如`auto`, `nullptr`, `override`等，它们具有特殊的语言含义。 16. **操作符和标点符(Operators and punctuators)**：详细描述了C++中的操作符，包括算术、比较、逻辑、赋值等，以及标点符号的用法。文档N3376对于C++ 11的深入学习和标准遵循至关重要，它不仅包含了语言的语法和语义，还涉及了编译器和运行时系统的实现细节。尽管是一个早期草案，但它仍为C++程序员和编译器开发者提供了宝贵的参考。

ISO/IEC N3376

1.3 Terms and deﬁnitions [intro.defs]

For the purposes of this document, the following deﬁnitions apply.

17.3 deﬁnes additional terms that are used only in Clauses 17 through 30 and Annex D.

Terms that are used only in a small portion of this International Standard are deﬁned where they are used

and italicized where they are deﬁned.

1.3.1 [defns.argument]

argument

actual argument

actual parameter

<function call expression> expression in the comma-separated list bounded by the parentheses

1.3.2 [defns.argument.macro]

argument

actual argument

actual parameter

<function-like macro> sequence of preprocessing tokens in the comma-separated list bounded by the paren-

theses

1.3.3 [defns.argument.throw]

argument

actual argument

actual parameter

<throw expression> the operand of throw

1.3.4 [defns.argument.templ]

argument

actual argument

actual parameter

<template instantiation> expression, type-id or template-name in the comma-separated list bounded by the

angle brackets

1.3.5 [defns.cond.supp]

conditionally-supported

program construct that an implementation is not required to support

[ Note: Each implementation documents all conditionally-supported constructs that it does not support. —

end note ]

1.3.6 [defns.diagnostic]

diagnostic message

message belonging to an implementation-deﬁned subset of the implementation’s output messages

1.3.7 [defns.dynamic.type]

dynamic type

<glvalue> type of the most derived object (1.8) to which the glvalue denoted by a glvalue expression refers

[ Example: if a pointer (8.3.1) p whose static type is “pointer to class B” is pointing to an object of class

D, derived from B (Clause 10), the dynamic type of the expression *p is “D.” References (8.3.2) are treated

similarly. — end example ]

1.3.8 [defns.dynamic.type.prvalue]

§ 1.3 2

ISO/IEC N3376

<function> name, parameter type list (8.3.5), and enclosing namespace (if any)

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

1.3.18 [defns.signature.templ]

signature

<function template> name, parameter type list (8.3.5), enclosing namespace (if any), return type, and

template parameter list

1.3.19 [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)

1.3.20 [defns.signature.member]

signature

<class member function> name, parameter type list (8.3.5), class of which the function is a member, cv-

qualiﬁers (if any), and ref-qualiﬁer (if any)

1.3.21 [defns.signature.member.templ]

signature

<class member function template> name, parameter type list (8.3.5), class of which the function is a member,

cv-qualiﬁers (if any), ref-qualiﬁer (if any), return type, and template parameter list

1.3.22 [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)

1.3.23 [defns.static.type]

static type

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

[ Note: 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 ]

1.3.24 [defns.undeﬁned]

undeﬁned behavior

behavior for which this International Standard imposes no requirements

[ Note: Undeﬁned behavior may be expected when this International Standard 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.

— end note ]

1.3.25 [defns.unspeciﬁed]

unspeciﬁed behavior

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

§ 1.3 4

ISO/IEC N3376

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

behaviors is usually delineated by this International Standard. — end note ]

1.3.26 [defns.well.formed]

well-formed program

program constructed according to the syntax rules, diagnosable semantic rules, and the One Deﬁnition

Rule (3.2).

1.4 Implementation compliance [intro.compliance]

The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard 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 International Standard 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:

— If a program contains no violations of the rules in this International Standard, a conforming imple-

mentation shall, within its resource limits, accept and correctly execute

that program.

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

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

a conforming implementation shall issue at least one diagnostic message.

— If a program contains a violation of a rule for which no diagnostic is required, this International

Standard places no requirement on implementations with respect to that program.

For classes and class templates, the library Clauses specify partial deﬁnitions. Private members (Clause 11)

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. Implemen-

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

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

translation unit (2.2) obtains access

to these names by including the appropriate standard library header (16.2).

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

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

complete C

program (2.2).

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

a hosted implementation, this International Standard 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 (17.6.1.3).

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 International Standard. 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.

1.5 Structure of this International Standard [intro.structure]

Clauses 2 through 16 describe the C

programming language. That description includes detailed syntactic

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

2) “Correct execution” can include undeﬁned behavior, depending on the data being processed; see 1.3 and 1.9.

3) This documentation also deﬁnes implementation-deﬁned behavior; see 1.9.

§ 1.5 5

ISO/IEC N3376

Clauses 18 through 30 and Annex D (the library clauses) describe the Standard C

library. That description

includes detailed descriptions of the templates, classes, functions, constants, and macros that constitute the

library, in a form described in Clause 17.

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.

Throughout this International Standard, each example is introduced by “[ Example:” and terminated by

“ — end example ]”. Each note is introduced by “[ Note:” and terminated by “ — end note ]”. Examples and

notes may be nested.

1.6 Syntax notation [syntax]

In the syntax notation used in this International Standard, syntactic categories are indicated by italic type,

and literal words and characters in constant width type. Alternatives are listed on separate lines except in

a few cases where a long set of alternatives is marked by the phrase “one of.” If the text of an alternative is

too long to ﬁt on a line, the text is continued on subsequent lines indented from the ﬁrst one. An optional

terminal or non-terminal symbol is indicated by the subscript “

opt

”, so

{ expression

opt

}

indicates an optional expression enclosed in braces.

Names for syntactic categories have generally been chosen according to the following rules:

— X-name is a use of an identiﬁer in a context that determines its meaning (e.g., class-name, typedef-

name).

— X-id is an identiﬁer with no context-dependent meaning (e.g., qualiﬁed-id).

— X-seq is one or more X’s without intervening delimiters (e.g., declaration-seq is a sequence of declara-

tions).

— X-list is one or more X’s separated by intervening commas (e.g., expression-list is a sequence of

expressions separated by commas).

1.7 The C

memory model [intro.memory]

The fundamental storage unit in the C

memory model is the byte. A byte is at least large enough to contain

any member of the basic execution character set (2.3) and the eight-bit code units of the Unicode UTF-8

encoding form and is composed of a contiguous sequence of bits, the number of which is implementation-

deﬁned. The least signiﬁcant bit is called the low-order bit; the most signiﬁcant bit is called the high-order

bit. The memory available to a C

program consists of one or more sequences of contiguous bytes. Every

byte has a unique address.

[ Note: The representation of types is described in 3.9. — end note ]

A memory location is either an object of scalar type or a maximal sequence of adjacent bit-ﬁelds all having

non-zero width. [ Note: Various features of the language, such as references and virtual functions, might

involve additional memory locations that are not accessible to programs but are managed by the imple-

mentation. — end note ] Two or more threads of execution (1.10) can update and access separate memory

locations without interfering with each other.

[ Note: Thus a bit-ﬁeld and an adjacent non-bit-ﬁeld are in separate memory locations, and therefore can be

concurrently updated by two threads of execution without interference. The same applies to two bit-ﬁelds,

if one is declared inside a nested struct declaration and the other is not, or if the two are separated by

a zero-length bit-ﬁeld declaration, or if they are separated by a non-bit-ﬁeld declaration. It is not safe to

concurrently update two bit-ﬁelds in the same struct if all ﬁelds between them are also bit-ﬁelds of non-zero

width. — end note ]

[ Example: A structure declared as

§ 1.7 6

剩余1323页未读，继续阅读

sj20082663

粉丝: 2
资源: 12

C++11标准文档N3376：编程语言C++的工作草案

C++中英文帮助文档

C++ 2017标准文档英文版

非常全面的c_c++教程（英文版）

C++标准库中vector的文档如何打开

如何通过合法途径获取C++标准ISO/IEC 14882-2011的电子版文档，并详细解释C++内存模型的核心要素？

c++20标准库有没有中文版

如何获取C++标准ISO/IEC 14882:2011(E)的电子版，并理解其关于C++内存模型的关键概念？

用c++但不用标准输入输入一行字符分别统计其中的英文字母，空格，数字和其他字符的个数 夸克AI · 通过学习全网内容智能生成 筛选结果类型 全部 资讯 图片 笔记 视频 文档 购物 已开启夸克AI增强模式

opendds 中文文档

为什么c++打不了中文变量

最新资源

用c++但不用标准输入输入一行字符分别统计其中的英文字母，空格，数字和其他字符的个数夸克AI · 通过学习全网内容智能生成筛选结果类型全部资讯图片笔记视频文档购物已开启夸克AI增强模式