[description] - C++14 → C++17

Files changed (1) hide show

tmp/tmpidgsu0ob/{from.md → to.md} +80 -58

tmp/tmpidgsu0ob/{from.md → to.md} RENAMED Viewed

@@ -7,16 +7,16 @@ library. [[structure]] describes the structure of the normative Clauses
 ### Structure of each clause <a id="structure">[[structure]]</a>
 #### Elements <a id="structure.elements">[[structure.elements]]</a>
-Each library clause contains the following elements, as applicable:[^2]
 - Summary
 - Requirements
 - Detailed specifications
-- References to the Standard C library
 #### Summary <a id="structure.summary">[[structure.summary]]</a>
 The Summary provides a synopsis of the category, and introduces the
 first-level subclauses. Each subclause also provides a summary, listing
@@ -50,12 +50,12 @@ The string and iostream components use an explicit representation of
 operations required of template arguments. They use a class template
 `char_traits` to define these constraints.
 Interface convention requirements are stated as generally as possible.
 Instead of stating “class X has to define a member function
-`operator++()`,” the interface requires “for any object `x` of class
-`X`, `++x` is defined.” That is, whether the operator is a member is
 unspecified.
 Requirements are stated in terms of well-defined expressions that define
 valid terms of the types that satisfy the requirements. For every set of
 well-defined expression requirements there is a table that specifies an
@@ -68,34 +68,34 @@ Template argument requirements are sometimes referenced by name. See
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++code. Such
 code is intended as a specification of equivalence of a construct to
 another construct, not necessarily as the way the construct must be
-implemented.[^3]
 #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
 The detailed specifications each contain the following elements:
 - name and brief description
-- synopsis (class definition or function prototype, as appropriate)
 - restrictions on template arguments, if any
 - description of class invariants
 - description of function semantics
 Descriptions of class member functions follow the order (as
-appropriate):[^4]
 - constructor(s) and destructor
 - copying, moving & assignment functions
 - comparison functions
 - modifier functions
 - observer functions
 - operators and other non-member functions
 Descriptions of function semantics contain the following elements (as
-appropriate):[^5]
 - *Requires:* the preconditions for calling the function
 - *Effects:* the actions performed by the function
 - *Synchronization:* the synchronization operations (
   [[intro.multithread]]) applicable to the function
@@ -104,24 +104,23 @@ appropriate):[^5]
 - *Throws:* any exceptions thrown by the function, and the conditions
   that would cause the exception
 - *Complexity:* the time and/or space complexity of the function
 - *Remarks:* additional semantic constraints on the function
 - *Error conditions:* the error conditions for error codes reported by
-  the function.
-- *Notes:* non-normative comments about the function
 Whenever the *Effects:* element specifies that the semantics of some
 function `F` are *Equivalent to* some code sequence, then the various
 elements are interpreted as follows. If `F`’s semantics specifies a
 *Requires:* element, then that requirement is logically imposed prior to
 the *equivalent-to* semantics. Next, the semantics of the code sequence
-are determined by the *Requires:* , *Effects:* , *Postconditions:* ,
-*Returns:* , *Throws:* , *Complexity:* , *Remarks:* , *Error
-conditions:* , and *Notes:* specified for the function invocations
 contained in the code sequence. The value returned from `F` is specified
 by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
-non-`void` return from `F` is specified by the *Returns:* elements in
 the code sequence. If `F`’s semantics contains a *Throws:* ,
 *Postconditions:* , or *Complexity:* element, then that supersedes any
 occurrences of that element in the code sequence.
 For non-reserved replacement and handler functions, Clause
@@ -132,11 +131,11 @@ describes a function definition provided by the implementation. The
 provided by either the implementation or a C++program. Where no
 distinction is explicitly made in the description, the behavior
 described is the required behavior.
 If the formulation of a complexity requirement calls for a negative
-number of operations, the actual requirement is zero operations.[^6]
 Complexity requirements specified in the library clauses are upper
 bounds, and implementations that provide better complexity guarantees
 satisfy the requirements.
@@ -145,12 +144,11 @@ conditions are listed, together with a suitable explanation, as the
 `enum class errc` constants ([[syserr]]).
 #### C library <a id="structure.see.also">[[structure.see.also]]</a>
 Paragraphs labeled “” contain cross-references to the relevant portions
-of this International Standard and the ISO C standard, which is
-incorporated into this International Standard by reference.
 ### Other conventions <a id="conventions">[[conventions]]</a>
 This subclause describes several editorial conventions used to describe
 the contents of the C++standard library. These conventions are for
@@ -160,37 +158,58 @@ member functions ([[functions.within.classes]]).
 #### Type descriptions <a id="type.descriptions">[[type.descriptions]]</a>
 ##### General <a id="type.descriptions.general">[[type.descriptions.general]]</a>
 The Requirements subclauses may describe names that are used to specify
-constraints on template arguments.[^7] These names are used in library
 Clauses to describe the types that may be supplied as arguments by a
 C++program when instantiating template components from the library.
 Certain types defined in Clause  [[input.output]] are used to describe
 implementation-defined types. They are based on other types, but with
 added constraints.
 ##### Enumerated types <a id="enumerated.types">[[enumerated.types]]</a>
 Several types defined in Clause  [[input.output]] are *enumerated
 types*. Each enumerated type may be implemented as an enumeration or as
-a synonym for an enumeration.[^8]
-The enumerated type *enumerated* can be written:
 ``` cpp
-enum enumerated { V0, V1, V2, V3, ..... };
-static const enumerated C0 (V0);
-static const enumerated C1 (V1);
-static const enumerated C2 (V2);
-static const enumerated C3 (V3);
   .....
 ```
-Here, the names *C0*, *C1*, etc. represent *enumerated elements* for
 this particular enumerated type. All such elements have distinct values.
 ##### Bitmask types <a id="bitmask.types">[[bitmask.types]]</a>
 Several types defined in Clauses  [[language.support]] through
@@ -200,20 +219,19 @@ operators, as an integer type, or as a `bitset` ([[template.bitset]]).
 The bitmask type *bitmask* can be written:
 ``` cpp
 // For exposition only.
-// int_type is an integral type capable of
-// representing all values of the bitmask type.
 enum bitmask : int_type {
- V0 = 1 << 0, V1 = 1 << 1, V2 = 1 << 2, V3 = 1 << 3, .....
 };
-constexpr bitmask C0(V0{});
-constexpr bitmask C1(V1{});
-constexpr bitmask C2(V2{});
-constexpr bitmask C3(V3{});
   .....
 constexpr bitmask{} operator&(bitmask{} X, bitmask{} Y) {
   return static_cast<bitmask{}>(
     static_cast<int_type>(X) & static_cast<int_type>(Y));
@@ -238,14 +256,14 @@ bitmask{}& operator|=(bitmask{}& X, bitmask{} Y) {
 bitmask{}& operator^=(bitmask{}& X, bitmask{} Y) {
   X = X ^ Y; return X;
 }
 ```
-Here, the names *C0*, *C1*, etc. represent *bitmask elements* for this
 particular bitmask type. All such elements have distinct, nonzero values
-such that, for any pair *Ci* and *Cj* where *i* != *j*, *Ci* & *Ci* is
-nonzero and *Ci* & *Cj* is zero. Additionally, the value 0 is used to
 represent an *empty bitmask*, in which no bitmask elements are set.
 The following terms apply to objects and values of bitmask types:
 - To *set* a value *Y* in an object *X* is to evaluate the expression
@@ -259,83 +277,87 @@ The following terms apply to objects and values of bitmask types:
 The C standard library makes widespread use of characters and character
 sequences that follow a few uniform conventions:
 - A *letter* is any of the 26 lowercase or 26 uppercase letters in the
-  basic execution character set.[^9]
 - The *decimal-point character* is the (single-byte) character used by
   functions that convert between a (single-byte) character sequence and
   a value of one of the floating-point types. It is used in the
   character sequence to denote the beginning of a fractional part. It is
   represented in Clauses  [[language.support]] through  [[thread]] and
   Annex  [[depr]] by a period, `'.'`, which is also its value in the
   `"C"` locale, but may change during program execution by a call to
-  `setlocale(int, const char*)`,[^10] or by a change to a `locale`
   object, as described in Clauses  [[locales]] and  [[input.output]].
-- A *character sequence* is an array object ([[dcl.array]]) *A* that
-  can be declared as `T A[N]`, where *T* is any of the types `char`,
   `unsigned char`, or `signed char` ([[basic.fundamental]]), optionally
   qualified by any combination of `const` or `volatile`. The initial
   elements of the array have defined contents up to and including an
   element determined by some predicate. A character sequence can be
-  designated by a pointer value *S* that points to its first element.
 ###### Byte strings <a id="byte.strings">[[byte.strings]]</a>
 A *null-terminated byte string*, or NTBS, is a character sequence whose
 highest-addressed element with defined content has the value zero (the
 *terminating null* character); no other element in the sequence has the
-value zero. [^11]
 The *length* of an NTBS is the number of elements that precede the
 terminating null character. An *empty* NTBS has a length of zero.
 The *value* of an NTBS is the sequence of values of the elements up to
 and including the terminating null character.
-A *static* NTBS is an NTBSwith static storage duration.[^12]
 ###### Multibyte strings <a id="multibyte.strings">[[multibyte.strings]]</a>
-A *null-terminated multibyte string,* or NTMBS, is an NTBSthat
 constitutes a sequence of valid multibyte characters, beginning and
-ending in the initial shift state.[^13]
 A *static* NTMBS is an NTMBSwith static storage duration.
 #### Functions within classes <a id="functions.within.classes">[[functions.within.classes]]</a>
 For the sake of exposition, Clauses  [[language.support]] through
 [[thread]] and Annex  [[depr]] do not describe copy/move constructors,
 assignment operators, or (non-virtual) destructors with the same
 apparent semantics as those that can be generated by default (
-[[class.ctor]], [[class.dtor]], [[class.copy]]).
-It is unspecified whether the implementation provides explicit
-definitions for such member function signatures, or for virtual
-destructors that can be generated by default.
 #### Private members <a id="objects.within.classes">[[objects.within.classes]]</a>
 Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]] do
 not specify the representation of classes, and intentionally omit
 specification of class members ([[class.mem]]). An implementation may
 define static or non-static class members, or both, as needed to
 implement the semantics of the member functions specified in Clauses
 [[language.support]] through  [[thread]] and Annex  [[depr]].
-Objects of certain classes are sometimes required by the external
-specifications of their classes to store data, apparently in member
-objects. For the sake of exposition, some subclauses provide
-representative declarations, and semantic requirements, for private
-member objects of classes that meet the external specifications of the
-classes. The declarations for such member objects and the definitions of
-related member types are followed by a comment that ends with
-*exposition only*, as in:
 ``` cpp
 streambuf* sb;  // exposition only
 ```
 An implementation may use any technique that provides equivalent
-external behavior.

 ### Structure of each clause <a id="structure">[[structure]]</a>
 #### Elements <a id="structure.elements">[[structure.elements]]</a>
+Each library clause contains the following elements, as applicable:[^1]
 - Summary
 - Requirements
 - Detailed specifications
+- References to the C standard library
 #### Summary <a id="structure.summary">[[structure.summary]]</a>
 The Summary provides a synopsis of the category, and introduces the
 first-level subclauses. Each subclause also provides a summary, listing
 operations required of template arguments. They use a class template
 `char_traits` to define these constraints.
 Interface convention requirements are stated as generally as possible.
 Instead of stating “class X has to define a member function
+`operator++()`”, the interface requires “for any object `x` of class
+`X`, `++x` is defined”. That is, whether the operator is a member is
 unspecified.
 Requirements are stated in terms of well-defined expressions that define
 valid terms of the types that satisfy the requirements. For every set of
 well-defined expression requirements there is a table that specifies an
 [[type.descriptions]].
 In some cases the semantic requirements are presented as C++code. Such
 code is intended as a specification of equivalence of a construct to
 another construct, not necessarily as the way the construct must be
+implemented.[^2]
 #### Detailed specifications <a id="structure.specifications">[[structure.specifications]]</a>
 The detailed specifications each contain the following elements:
 - name and brief description
+- synopsis (class definition or function declaration, as appropriate)
 - restrictions on template arguments, if any
 - description of class invariants
 - description of function semantics
 Descriptions of class member functions follow the order (as
+appropriate):[^3]
 - constructor(s) and destructor
 - copying, moving & assignment functions
 - comparison functions
 - modifier functions
 - observer functions
 - operators and other non-member functions
 Descriptions of function semantics contain the following elements (as
+appropriate):[^4]
 - *Requires:* the preconditions for calling the function
 - *Effects:* the actions performed by the function
 - *Synchronization:* the synchronization operations (
   [[intro.multithread]]) applicable to the function
 - *Throws:* any exceptions thrown by the function, and the conditions
   that would cause the exception
 - *Complexity:* the time and/or space complexity of the function
 - *Remarks:* additional semantic constraints on the function
 - *Error conditions:* the error conditions for error codes reported by
+  the function
 Whenever the *Effects:* element specifies that the semantics of some
 function `F` are *Equivalent to* some code sequence, then the various
 elements are interpreted as follows. If `F`’s semantics specifies a
 *Requires:* element, then that requirement is logically imposed prior to
 the *equivalent-to* semantics. Next, the semantics of the code sequence
+are determined by the *Requires:* , *Effects:* , *Synchronization:* ,
+*Postconditions:* , *Returns:* , *Throws:* , *Complexity:* , *Remarks:*
+, and *Error conditions:* specified for the function invocations
 contained in the code sequence. The value returned from `F` is specified
 by `F`’s *Returns:* element, or if `F` has no *Returns:* element, a
+non-`void` return from `F` is specified by the `return` statements in
 the code sequence. If `F`’s semantics contains a *Throws:* ,
 *Postconditions:* , or *Complexity:* element, then that supersedes any
 occurrences of that element in the code sequence.
 For non-reserved replacement and handler functions, Clause
 provided by either the implementation or a C++program. Where no
 distinction is explicitly made in the description, the behavior
 described is the required behavior.
 If the formulation of a complexity requirement calls for a negative
+number of operations, the actual requirement is zero operations.[^5]
 Complexity requirements specified in the library clauses are upper
 bounds, and implementations that provide better complexity guarantees
 satisfy the requirements.
 `enum class errc` constants ([[syserr]]).
 #### C library <a id="structure.see.also">[[structure.see.also]]</a>
 Paragraphs labeled “” contain cross-references to the relevant portions
+of this International Standard and the ISO C standard.
 ### Other conventions <a id="conventions">[[conventions]]</a>
 This subclause describes several editorial conventions used to describe
 the contents of the C++standard library. These conventions are for
 #### Type descriptions <a id="type.descriptions">[[type.descriptions]]</a>
 ##### General <a id="type.descriptions.general">[[type.descriptions.general]]</a>
 The Requirements subclauses may describe names that are used to specify
+constraints on template arguments.[^6] These names are used in library
 Clauses to describe the types that may be supplied as arguments by a
 C++program when instantiating template components from the library.
 Certain types defined in Clause  [[input.output]] are used to describe
 implementation-defined types. They are based on other types, but with
 added constraints.
+##### Exposition-only types <a id="expos.only.types">[[expos.only.types]]</a>
+Several types defined in Clauses  [[language.support]] through
+[[thread]] and Annex  [[depr]] that are used as function parameter or
+return types are defined for the purpose of exposition only in order to
+capture their language linkage. The declarations of such types are
+followed by a comment ending in *exposition only*.
+[*Example 1*:
+``` cpp
+namespace std {
+  extern "C" using some-handler = int(int, void*, double);  // exposition only
+}
+```
+The type placeholder `some-handler` can now be used to specify a
+function that takes a callback parameter with C language linkage.
+— *end example*]
 ##### Enumerated types <a id="enumerated.types">[[enumerated.types]]</a>
 Several types defined in Clause  [[input.output]] are *enumerated
 types*. Each enumerated type may be implemented as an enumeration or as
+a synonym for an enumeration.[^7]
+The enumerated type `enumerated` can be written:
 ``` cpp
+enum enumerated { V₀, V₁, V₂, V₃, ..... };
+inline const enumerated C₀(V₀);
+inline const enumerated C₁(V₁);
+inline const enumerated C₂(V₂);
+inline const enumerated C₃(V₃);
   .....
 ```
+Here, the names `C₀`, `C₁`, etc. represent *enumerated elements* for
 this particular enumerated type. All such elements have distinct values.
 ##### Bitmask types <a id="bitmask.types">[[bitmask.types]]</a>
 Several types defined in Clauses  [[language.support]] through
 The bitmask type *bitmask* can be written:
 ``` cpp
 // For exposition only.
+// int_type is an integral type capable of representing all values of the bitmask type.
 enum bitmask : int_type {
+ V₀ = 1 << 0, V₁ = 1 << 1, V₂ = 1 << 2, V₃ = 1 << 3, .....
 };
+inline constexpr bitmask C₀(V₀{});
+inline constexpr bitmask C₁(V₁{});
+inline constexpr bitmask C₂(V₂{});
+inline constexpr bitmask C₃(V₃{});
   .....
 constexpr bitmask{} operator&(bitmask{} X, bitmask{} Y) {
   return static_cast<bitmask{}>(
     static_cast<int_type>(X) & static_cast<int_type>(Y));
 bitmask{}& operator^=(bitmask{}& X, bitmask{} Y) {
   X = X ^ Y; return X;
 }
 ```
+Here, the names `C₀`, `C₁`, etc. represent *bitmask elements* for this
 particular bitmask type. All such elements have distinct, nonzero values
+such that, for any pair `Cᵢ` and `Cⱼ` where i ≠ j, `C_i & C_i` is
+nonzero and `C_i & C_j` is zero. Additionally, the value `0` is used to
 represent an *empty bitmask*, in which no bitmask elements are set.
 The following terms apply to objects and values of bitmask types:
 - To *set* a value *Y* in an object *X* is to evaluate the expression
 The C standard library makes widespread use of characters and character
 sequences that follow a few uniform conventions:
 - A *letter* is any of the 26 lowercase or 26 uppercase letters in the
+  basic execution character set.
 - The *decimal-point character* is the (single-byte) character used by
   functions that convert between a (single-byte) character sequence and
   a value of one of the floating-point types. It is used in the
   character sequence to denote the beginning of a fractional part. It is
   represented in Clauses  [[language.support]] through  [[thread]] and
   Annex  [[depr]] by a period, `'.'`, which is also its value in the
   `"C"` locale, but may change during program execution by a call to
+  `setlocale(int, const char*)`,[^8] or by a change to a `locale`
   object, as described in Clauses  [[locales]] and  [[input.output]].
+- A *character sequence* is an array object ([[dcl.array]]) `A` that
+  can be declared as `T A[N]`, where `T` is any of the types `char`,
   `unsigned char`, or `signed char` ([[basic.fundamental]]), optionally
   qualified by any combination of `const` or `volatile`. The initial
   elements of the array have defined contents up to and including an
   element determined by some predicate. A character sequence can be
+  designated by a pointer value `S` that points to its first element.
 ###### Byte strings <a id="byte.strings">[[byte.strings]]</a>
 A *null-terminated byte string*, or NTBS, is a character sequence whose
 highest-addressed element with defined content has the value zero (the
 *terminating null* character); no other element in the sequence has the
+value zero. [^9]
 The *length* of an NTBS is the number of elements that precede the
 terminating null character. An *empty* NTBS has a length of zero.
 The *value* of an NTBS is the sequence of values of the elements up to
 and including the terminating null character.
+A *static* NTBS is an NTBSwith static storage duration.[^10]
 ###### Multibyte strings <a id="multibyte.strings">[[multibyte.strings]]</a>
+A *null-terminated multibyte string*, or NTMBS, is an NTBSthat
 constitutes a sequence of valid multibyte characters, beginning and
+ending in the initial shift state.[^11]
 A *static* NTMBS is an NTMBSwith static storage duration.
 #### Functions within classes <a id="functions.within.classes">[[functions.within.classes]]</a>
 For the sake of exposition, Clauses  [[language.support]] through
 [[thread]] and Annex  [[depr]] do not describe copy/move constructors,
 assignment operators, or (non-virtual) destructors with the same
 apparent semantics as those that can be generated by default (
+[[class.ctor]], [[class.dtor]], [[class.copy]]). It is unspecified
+whether the implementation provides explicit definitions for such member
+function signatures, or for virtual destructors that can be generated by
+default.
+For the sake of exposition, the library clauses sometimes annotate
+constructors with \EXPLICIT. Such a constructor is conditionally
+declared as either explicit or non-explicit ([[class.conv.ctor]]).
+[*Note 1*: This is typically implemented by declaring two such
+constructors, of which at most one participates in overload
+resolution. — *end note*]
 #### Private members <a id="objects.within.classes">[[objects.within.classes]]</a>
 Clauses  [[language.support]] through  [[thread]] and Annex  [[depr]] do
 not specify the representation of classes, and intentionally omit
 specification of class members ([[class.mem]]). An implementation may
 define static or non-static class members, or both, as needed to
 implement the semantics of the member functions specified in Clauses
 [[language.support]] through  [[thread]] and Annex  [[depr]].
+For the sake of exposition, some subclauses provide representative
+declarations, and semantic requirements, for private members of classes
+that meet the external specifications of the classes. The declarations
+for such members are followed by a comment that ends with *exposition
+only*, as in:
 ``` cpp
 streambuf* sb;  // exposition only
 ```
 An implementation may use any technique that provides equivalent
+observable behavior.

Diff to HTML by rtfpessoa