Working Draft, Standard for Programming Language C++ (N4713, 2017 year) - page 44
C.1.2
Clause 6: basic concepts
[diff.basic]
1
Affected subclause: 6.1
Change: C++ does not have “tentative definitions” as in C.
E.g., at file scope,
int i;
int i;
is valid in C, invalid in C++. This makes it impossible to define mutually referential file-local static objects,
if initializers are restricted to the syntactic forms of C. For example,
struct X { int i; struct X* next; };
static struct X a;
static struct X b = { 0, &a };
static struct X a = { 1, &b };
Rationale: This avoids having different initialization rules for fundamental types and user-defined types.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. In C++, the initializer for one of a set of mutually-
referential file-local static objects must invoke a function call to achieve the initialization.
How widely used: Seldom.
2
Affected subclause: 6.3
Change: A struct is a scope in C++, not in C.
Rationale: Class scope is crucial to C++, and a struct is a class.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: C programs use struct extremely frequently, but the change is only noticeable when
struct, enumeration, or enumerator names are referred to outside the struct. The latter is probably rare.
3
Affected subclause: 6.5 [also 10.1.7]
Change: A name of file scope that is explicitly declared const, and not explicitly declared extern, has
internal linkage, while in C it would have external linkage.
Rationale: Because const objects may be used as values during translation in C++, this feature urges
programmers to provide an explicit initializer for each const object. This feature allows the user to put const
objects in source files that are included in more than one translation unit.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: Seldom.
4
Affected subclause: 6.8.3.1
Change: The main function cannot be called recursively and cannot have its address taken.
Rationale: The main function may require special actions.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Trivial: create an intermediary function such as mymain(argc, argv).
How widely used: Seldom.
5
Affected subclause: 6.7
Change: C allows “compatible types” in several places, C++ does not.
For example, otherwise-identical struct types with different tag names are “compatible” in C but are
distinctly different types in C++.
Rationale: Stricter type checking is essential for C++.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. The “typesafe linkage” mechanism will find many, but
not all, of such problems. Those problems not found by typesafe linkage will continue to function properly,
according to the “layout compatibility rules” of this document.
How widely used: Common.
C.1.3
Clause 7: standard conversions
[diff.conv]
1
Affected subclause: 7.11
Change: Converting void* to a pointer-to-object type requires casting.
char a[10];
§ C.1.3
1282
void* b=a;
void foo() {
char* c=b;
}
ISO C will accept this usage of pointer to void being assigned to a pointer to object type. C++ will not.
Rationale: C++ tries harder than C to enforce compile-time type safety.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Could be automated. Violations will be diagnosed by the C++ translator. The
fix is to add a cast. For example:
char* c = (char*) b;
How widely used: This is fairly widely used but it is good programming practice to add the cast when
assigning pointer-to-void to pointer-to-object. Some ISO C translators will give a warning if the cast is not
used.
C.1.4
Clause 8: expressions
[diff.expr]
1
Affected subclause: 8.5.1.2
Change: Implicit declaration of functions is not allowed.
Rationale: The type-safe nature of C++.
Effect on original feature: Deletion of semantically well-defined feature. Note: the original feature was
labeled as “obsolescent” in ISO C.
Difficulty of converting: Syntactic transformation. Facilities for producing explicit function declarations
are fairly widespread commercially.
How widely used: Common.
2
Affected subclause: 8.5.1.6, 8.5.2.2
Change: Decrement operator is not allowed with bool operand.
Rationale: Feature with surprising semantics.
Effect on original feature: A valid ISO C expression utilizing the decrement operator on a bool lvalue
(for instance, via the C typedef in <stdbool.h>) is ill-formed in this International Standard.
3
Affected subclause: 8.5.2.3, 8.5.3
Change: Types must be defined in declarations, not in expressions.
In C, a sizeof expression or cast expression may define a new type. For example,
p = (void*)(struct x {int i;} *)0;
defines a new type, struct x.
Rationale: This prohibition helps to clarify the location of definitions in the source code.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation.
How widely used: Seldom.
4
Affected subclause: 8.5.16, 8.5.18, 8.5.19
Change: The result of a conditional expression, an assignment expression, or a comma expression may be
an lvalue.
Rationale: C++ is an object-oriented language, placing relatively more emphasis on lvalues. For example,
functions may return lvalues.
Effect on original feature: Change to semantics of well-defined feature. Some C expressions that implicitly
rely on lvalue-to-rvalue conversions will yield different results. For example,
char arr[100];
sizeof(0, arr)
yields 100 in C++ and sizeof(char*) in C.
Difficulty of converting: Programs must add explicit casts to the appropriate rvalue.
How widely used: Rare.
C.1.5
Clause 9: statements
[diff.stat]
1
Affected subclause: 9.4.2, 9.6.4
Change: It is now invalid to jump past a declaration with explicit or implicit initializer (except across entire
block not entered).
§ C.1.5
1283
Rationale: Constructors used in initializers may allocate resources which need to be de-allocated upon
leaving the block. Allowing jump past initializers would require complicated runtime determination of
allocation. Furthermore, any use of the uninitialized object could be a disaster. With this simple compile-time
rule, C++ assures that if an initialized variable is in scope, then it has assuredly been initialized.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: Seldom.
2
Affected subclause: 9.6.3
Change: It is now invalid to return (explicitly or implicitly) from a function which is declared to return a
value without actually returning a value.
Rationale: The caller and callee may assume fairly elaborate return-value mechanisms for the return of class
objects. If some flow paths execute a return without specifying any value, the implementation must embody
many more complications. Besides, promising to return a value of a given type, and then not returning such
a value, has always been recognized to be a questionable practice, tolerated only because very-old C had no
distinction between void functions and int functions.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. Add an appropriate return value to the source code,
such as zero.
How widely used: Seldom. For several years, many existing C implementations have produced warnings in
this case.
C.1.6
Clause 10: declarations
[diff.dcl]
1
Affected subclause: 10.1.1
Change: In C++, the static or extern specifiers can only be applied to names of objects or functions.
Using these specifiers with type declarations is illegal in C++. In C, these specifiers are ignored when used on
type declarations.
Example:
static struct S {
// valid C, invalid in C++
int i;
};
Rationale: Storage class specifiers don’t have any meaning when associated with a type. In C++, class
members can be declared with the static storage class specifier. Allowing storage class specifiers on type
declarations could render the code confusing for users.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation.
How widely used: Seldom.
2
Affected subclause: 10.1.1
Change: In C++, register is not a storage class specifier.
Rationale: The storage class specifier had no effect in C++.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation.
How widely used: Common.
3
Affected subclause: 10.1.3
Change: A C++ typedef name must be different from any class type name declared in the same scope
(except if the typedef is a synonym of the class name with the same name). In C, a typedef name and a struct
tag name declared in the same scope can have the same name (because they have different name spaces).
Example:
typedef struct name1 { /* ... */ } name1;
// valid C and C++
struct name { /* ... */ };
typedef int name;
// valid C, invalid C++
Rationale: For ease of use, C++ doesn’t require that a type name be prefixed with the keywords class,
struct or union when used in object declarations or type casts.
Example:
§ C.1.6
1284
class name { /* ... */ };
name i;
// i has type class name
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. One of the 2 types has to be renamed.
How widely used: Seldom.
4
Affected subclause: 10.1.7 [see also 6.5]
Change: const objects must be initialized in C++ but can be left uninitialized in C.
Rationale: A const object cannot be assigned to so it must be initialized to hold a useful value.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: Seldom.
5
Affected subclause: 10.1.7
Change: Banning implicit int.
In C++ a decl-specifier-seq must contain a type-specifier , unless it is followed by a declarator for a constructor,
a destructor, or a conversion function. In the following example, the left-hand column presents valid C; the
right-hand column presents equivalent C++ :
void f(const parm);
void f(const int parm);
const n = 3;
const int n = 3;
main()
int main()
/* ... */
/* ... */
Rationale: In C++, implicit int creates several opportunities for ambiguity between expressions involving
function-like casts and declarations. Explicit declaration is increasingly considered to be proper style. Liaison
with WG14 (C) indicated support for (at least) deprecating implicit int in the next revision of C.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation. Could be automated.
How widely used: Common.
6
Affected subclause: 10.1.7.4
Change: The keyword auto cannot be used as a storage class specifier.
void f() {
auto int x;
// valid C, invalid C++
}
Rationale: Allowing the use of auto to deduce the type of a variable from its initializer results in undesired
interpretations of auto as a storage class specifier in certain contexts.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation.
How widely used: Rare.
7
Affected subclause: 10.2
Change: C++ objects of enumeration type can only be assigned values of the same enumeration type. In C,
objects of enumeration type can be assigned values of any integral type.
Example:
enum color { red, blue, green };
enum color c = 1;
// valid C, invalid C++
Rationale: The type-safe nature of C++.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation. (The type error produced by the assignment can be
automatically corrected by applying an explicit cast.)
How widely used: Common.
8
Affected subclause: 10.2
Change: In C++, the type of an enumerator is its enumeration. In C, the type of an enumerator is int.
Example:
§ C.1.6
1285
enum e { A };
sizeof(A) == sizeof(int)
// in C
sizeof(A) == sizeof(e)
// in C++
/∗ and sizeof(int) is not necessarily equal to sizeof(e) ∗/
Rationale: In C++, an enumeration is a distinct type.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: Seldom. The only time this affects existing C code is when the size of an enumerator is
taken. Taking the size of an enumerator is not a common C coding practice.
C.1.7
Clause 11: declarators
[diff.decl]
1
Affected subclause: 11.3.5
Change: In C++, a function declared with an empty parameter list takes no arguments. In C, an empty
parameter list means that the number and type of the function arguments are unknown.
Example:
int f();
// means int f(void) in C++
// int f( unknown ) in C
Rationale: This is to avoid erroneous function calls (i.e., function calls with the wrong number or type of
arguments).
Effect on original feature: Change to semantics of well-defined feature. This feature was marked as
“obsolescent” in C.
Difficulty of converting: Syntactic transformation. The function declarations using C incomplete declara-
tion style must be completed to become full prototype declarations. A program may need to be updated
further if different calls to the same (non-prototype) function have different numbers of arguments or if the
type of corresponding arguments differed.
How widely used: Common.
2
Affected subclause: 11.3.5 [see 8.5.2.3]
Change: In C++, types may not be defined in return or parameter types. In C, these type definitions are
allowed.
Example:
void f( struct S { int a; } arg ) {}
// valid C, invalid C++
enum E { A, B, C } f() {}
// valid C, invalid C++
Rationale: When comparing types in different translation units, C++ relies on name equivalence when C
relies on structural equivalence. Regarding parameter types: since the type defined in a parameter list would
be in the scope of the function, the only legal calls in C++ would be from within the function itself.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. The type definitions must be moved to file scope, or
in header files.
How widely used: Seldom. This style of type definition is seen as poor coding style.
3
Affected subclause: 11.4
Change: In C++, the syntax for function definition excludes the “old-style” C function. In C, “old-style”
syntax is allowed, but deprecated as “obsolescent”.
Rationale: Prototypes are essential to type safety.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Syntactic transformation.
How widely used: Common in old programs, but already known to be obsolescent.
4
Affected subclause: 11.6.1
Change: In C++, designated initialization support is restricted compared to the corresponding functionality
in C. In C++, designators for non-static data members must be specified in declaration order, designators
for array elements and nested designators are not supported, and designated and non-designated initializers
cannot be mixed in the same initializer list.
Example:
§ C.1.7
1286
struct A { int x, y; };
struct B { struct A a; };
struct A a = {.y = 1, .x = 2};
// valid C, invalid C++
int arr[3] = {[1] = 5};
// valid C, invalid C++
struct B b = {.a.x = 0};
// valid C, invalid C++
struct A c = {.x = 1, 2};
// valid C, invalid C++
Rationale: In C++, members are destroyed in reverse construction order and the elements of an initializer
list are evaluated in lexical order, so field initializers must be specified in order. Array designators conflict
with lambda-expression syntax. Nested designators are seldom used.
Effect on original feature: Deletion of feature that is incompatible with C++.
Difficulty of converting: Syntactic transformation.
How widely used: Out-of-order initializers are common. The other features are seldom used.
5
Affected subclause: 11.6.2
Change: In C++, when initializing an array of character with a string, the number of characters in the
string (including the terminating ’\0’) must not exceed the number of elements in the array. In C, an array
can be initialized with a string even if the array is not large enough to contain the string-terminating ’\0’.
Example:
char array[4] = "abcd";
// valid C, invalid C++
Rationale: When these non-terminated arrays are manipulated by standard string functions, there is
potential for major catastrophe.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. The arrays must be declared one element bigger to
contain the string terminating ’\0’.
How widely used: Seldom. This style of array initialization is seen as poor coding style.
C.1.8
Clause 12: classes
[diff.class]
1
Affected subclause: 12.1 [see also 10.1.3]
Change: In C++, a class declaration introduces the class name into the scope where it is declared and hides
any object, function or other declaration of that name in an enclosing scope. In C, an inner scope declaration
of a struct tag name never hides the name of an object or function in an outer scope.
Example:
int x[99];
void f() {
struct x { int a; };
sizeof(x);
/∗ size of the array in C ∗/
/∗ size of the struct in C++ ∗/
}
Rationale: This is one of the few incompatibilities between C and C++ that can be attributed to the new
C++ name space definition where a name can be declared as a type and as a non-type in a single scope
causing the non-type name to hide the type name and requiring that the keywords class, struct, union
or enum be used to refer to the type name. This new name space definition provides important notational
conveniences to C++ programmers and helps making the use of the user-defined types as similar as possible
to the use of fundamental types. The advantages of the new name space definition were judged to outweigh
by far the incompatibility with C described above.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation. If the hidden name that needs to be accessed is at
global scope, the :: C++ operator can be used. If the hidden name is at block scope, either the type or the
struct tag has to be renamed.
How widely used: Seldom.
2
Affected subclause: 12.2.4
Change: Bit-fields of type plain int are signed.
Rationale: Leaving the choice of signedness to implementations could lead to inconsistent definitions of
template specializations. For consistency, the implementation freedom was eliminated for non-dependent
§ C.1.8
1287
types, too.
Effect on original feature: The choice is implementation-defined in C, but not so in C++.
Difficulty of converting: Syntactic transformation.
How widely used: Seldom.
3
Affected subclause: 12.2.5
Change: In C++, the name of a nested class is local to its enclosing class. In C the name of the nested class
belongs to the same scope as the name of the outermost enclosing class.
Example:
struct X {
struct Y { /* ... */ } y;
};
struct Y yy;
// valid C, invalid C++
Rationale: C++ classes have member functions which require that classes establish scopes. The C rule would
leave classes as an incomplete scope mechanism which would prevent C++ programmers from maintaining
locality within a class. A coherent set of scope rules for C++ based on the C rule would be very complicated
and C++ programmers would be unable to predict reliably the meanings of nontrivial examples involving
nested or local functions.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation. To make the struct type name visible in the scope of
the enclosing struct, the struct tag could be declared in the scope of the enclosing struct, before the enclosing
struct is defined. Example:
struct Y;
// struct Y and struct X are at the same scope
struct X {
struct Y { /* ... */ } y;
};
All the definitions of C struct types enclosed in other struct definitions and accessed outside the scope of the
enclosing struct could be exported to the scope of the enclosing struct. Note: this is a consequence of the
difference in scope rules, which is documented in 6.3.
How widely used: Seldom.
4
Affected subclause: 12.2.6
Change: In C++, a typedef name may not be redeclared in a class definition after being used in that
definition.
Example:
typedef int I;
struct S {
I i;
int I;
// valid C, invalid C++
};
Rationale: When classes become complicated, allowing such a redefinition after the type has been used can
create confusion for C++ programmers as to what the meaning of I really is.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. Either the type or the struct member has to be
renamed.
How widely used: Seldom.
C.1.9
Clause 15: special member functions
[diff.special]
1
Affected subclause: 15.8
Change: Copying volatile objects.
The implicitly-declared copy constructor and implicitly-declared copy assignment operator cannot make a
copy of a volatile lvalue. For example, the following is valid in ISO C:
struct X { int i; };
volatile struct X x1 = {0};
struct X x2 = x1;
// invalid C++
struct X x3;
§ C.1.9
1288
x3 = x1;
// also invalid C++
Rationale: Several alternatives were debated at length. Changing the parameter to volatile const X&
would greatly complicate the generation of efficient code for class objects. Discussion of providing two
alternative signatures for these implicitly-defined operations raised unanswered concerns about creating
ambiguities and complicating the rules that specify the formation of these operators according to the bases
and members.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. If volatile semantics are required for the copy, a
user-declared constructor or assignment must be provided. If non-volatile semantics are required, an explicit
const_cast can be used.
How widely used: Seldom.
C.1.10
Clause 19: preprocessing directives
[diff.cpp]
1
Affected subclause: 19.8
Change: Whether __STDC__ is defined and if so, what its value is, are implementation-defined.
Rationale: C++ is not identical to ISO C. Mandating that __STDC__ be defined would require that
translators make an incorrect claim. Each implementation must choose the behavior that will be most useful
to its marketplace.
Effect on original feature: Change to semantics of well-defined feature.
Difficulty of converting: Semantic transformation.
How widely used: Programs and headers that reference __STDC__ are quite common.
C.2
C++ and ISO C++ 2003
[diff.cpp03]
1
This subclause lists the differences between C++ and ISO C++ 2003 (ISO/IEC 14882:2003, Programming
Languages — C++), by the chapters of this document.
C.2.1
Clause 5: lexical conventions
[diff.cpp03.lex]
1
Affected subclause: 5.4
Change: New kinds of string literals.
Rationale: Required for new features.
Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this
International Standard. Specifically, macros named R, u8, u8R, u, uR, U, UR, or LR will not be expanded when
adjacent to a string literal but will be interpreted as part of the string literal. For example,
#define u8 "abc"
const char* s = u8"def";
// Previously "abcdef", now "def"
2
Affected subclause: 5.4
Change: User-defined literal string support.
Rationale: Required for new features.
Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this
International Standard, as the following example illustrates.
#define _x "there"
"hello"_x
// #1
Previously, #1 would have consisted of two separate preprocessing tokens and the macro _x would have been
expanded. In this International Standard, #1 consists of a single preprocessing token, so the macro is not
expanded.
3
Affected subclause: 5.11
Change: New keywords.
Rationale: Required for new features.
Effect on original feature: Added to Table 5, the following identifiers are new keywords: alignas, alignof,
char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, and thread_local. Valid
C++ 2003 code using these identifiers is invalid in this International Standard.
4
Affected subclause: 5.13.2
Change: Type of integer literals.
Rationale: C99 compatibility.
§ C.2.1
1289
Effect on original feature: Certain integer literals larger than can be represented by long could change
from an unsigned integer type to signed long long.
C.2.2
Clause 7: standard conversions
[diff.cpp03.conv]
1
Affected subclause: 7.11
Change: Only literals are integer null pointer constants.
Rationale: Removing surprising interactions with templates and constant expressions.
Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this
International Standard, as the following example illustrates:
void f(void *);
// #1
void f(...);
// #2
template<int N> void g() {
f(0*N);
// calls #2; used to call #1
}
C.2.3
Clause 8: expressions
[diff.cpp03.expr]
1
Affected subclause: 8.5.5
Change: Specify rounding for results of integer / and %.
Rationale: Increase portability, C99 compatibility.
Effect on original feature: Valid C++ 2003 code that uses integer division rounds the result toward 0 or
toward negative infinity, whereas this International Standard always rounds the result toward 0.
2
Affected subclause: 8.5.14
Change: && is valid in a type-name.
Rationale: Required for new features.
Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this
International Standard, as the following example illustrates:
bool b1 = new int && false;
// previously false, now ill-formed
struct S { operator int(); };
bool b2 = &S::operator int && false;
// previously false, now ill-formed
C.2.4
Clause 10: declarations
[diff.cpp03.dcl.dcl]
1
Affected subclause: 10.1
Change: Remove auto as a storage class specifier.
Rationale: New feature.
Effect on original feature: Valid C++ 2003 code that uses the keyword auto as a storage class specifier
may be invalid in this International Standard. In this International Standard, auto indicates that the type of
a variable is to be deduced from its initializer expression.
C.2.5
Clause 11: declarators
[diff.cpp03.dcl.decl]
1
Affected subclause: 11.6.4
Change: Narrowing restrictions in aggregate initializers.
Rationale: Catches bugs.
Effect on original feature: Valid C++ 2003 code may fail to compile in this International Standard. For
example, the following code is valid in C++ 2003 but invalid in this International Standard because double
to int is a narrowing conversion:
int x[] = { 2.0 };
C.2.6
Clause 15: special member functions
[diff.cpp03.special]
1
Affected subclause: 15.1, 15.4, 15.8
Change: Implicitly-declared special member functions are defined as deleted when the implicit definition
would have been ill-formed.
Rationale: Improves template argument deduction failure.
Effect on original feature: A valid C++ 2003 program that uses one of these special member functions
in a context where the definition is not required (e.g., in an expression that is not potentially evaluated)
becomes ill-formed.
2
Affected subclause: 15.4
Change: User-declared destructors have an implicit exception specification.
§ C.2.6
1290
Rationale: Clarification of destructor requirements.
Effect on original feature: Valid C++ 2003 code may execute differently in this International Standard. In
particular, destructors that throw exceptions will call std::terminate (without calling std::unexpected)
if their exception specification is non-throwing.
C.2.7
Clause 17: templates
[diff.cpp03.temp]
1
Affected subclause: 17.1
Change: Remove export.
Rationale: No implementation consensus.
Effect on original feature: A valid C++ 2003 declaration containing export is ill-formed in this Interna-
tional Standard.
2
Affected subclause: 17.3
Change: Remove whitespace requirement for nested closing template right angle brackets.
Rationale: Considered a persistent but minor annoyance. Template aliases representing non-class types
would exacerbate whitespace issues.
Effect on original feature: Change to semantics of well-defined expression. A valid C++ 2003 expression
containing a right angle bracket (“>”) followed immediately by another right angle bracket may now be
treated as closing two templates. For example, the following code is valid in C++ 2003 because “>>” is a
right-shift operator, but invalid in this International Standard because “>>” closes two templates.
template <class T> struct X { };
template <int N> struct Y { };
X< Y< 1 >> 2 > > x;
3
Affected subclause: 17.7.4.2
Change: Allow dependent calls of functions with internal linkage.
Rationale: Overly constrained, simplify overload resolution rules.
Effect on original feature: A valid C++ 2003 program could get a different result than this International
Standard.
C.2.8
Clause 20: library introduction
[diff.cpp03.library]
1
Affected: Clause 20 - Clause 33
Change: New reserved identifiers.
Rationale: Required by new features.
Effect on original feature: Valid C++ 2003 code that uses any identifiers added to the C++ standard
library by this International Standard may fail to compile or produce different results in this International
Standard. A comprehensive list of identifiers used by the C++ standard library can be found in the Index of
Library Names in this International Standard.
2
Affected subclause: 20.5.1.2
Change: New headers.
Rationale: New functionality.
Effect on original feature: The following C++ headers are new: <array>, <atomic>, <chrono>, <codecvt>,
<condition_variable>, <forward_list>, <future>, <initializer_list>, <mutex>, <random>, <ratio>,
<regex>, <scoped_allocator>, <system_error>, <thread>, <tuple>, <typeindex>, <type_traits>,
<unordered_map>, and <unordered_set>. In addition the following C compatibility headers are new:
<ccomplex>, <cfenv>, <cinttypes>, <cstdalign>, <cstdbool>, <cstdint>, <ctgmath>, and <cuchar>.
Valid C++ 2003 code that #includes headers with these names may be invalid in this International Standard.
3
Affected subclause: 20.5.3.2
Effect on original feature: Function swap moved to a different header
Rationale: Remove dependency on <algorithm> for swap.
Effect on original feature: Valid C++ 2003 code that has been compiled expecting swap to be in
<algorithm> may have to instead include <utility>.
4
Affected subclause: 20.5.4.2.2
Change: New reserved namespace.
Rationale: New functionality.
Effect on original feature: The global namespace posix is now reserved for standardization. Valid C++
2003 code that uses a top-level namespace posix may be invalid in this International Standard.
§ C.2.8
1291
5
Affected subclause: 20.5.5.3
Change: Additional restrictions on macro names.
Rationale: Avoid hard to diagnose or non-portable constructs.
Effect on original feature: Names of attribute identifiers may not be used as macro names. Valid C++
2003 code that defines override, final, carries_dependency, or noreturn as macros is invalid in this
International Standard.
C.2.9
Clause 21: language support library
[diff.cpp03.language.support]
1
Affected subclause: 21.6.2.1
Change: Linking new and delete operators.
Rationale: The two throwing single-object signatures of operator new and operator delete are now
specified to form the base functionality for the other operators. This clarifies that replacing just these two
signatures changes others, even if they are not explicitly changed.
Effect on original feature: Valid C++ 2003 code that replaces global new or delete operators may
execute differently in this International Standard. For example, the following program should write "custom
deallocation" twice, once for the single-object delete and once for the array delete.
#include <cstdio>
#include <cstdlib>
#include <new>
void* operator new(std::size_t size) throw(std::bad_alloc) {
return std::malloc(size);
}
void operator delete(void* ptr) throw() {
std::puts("custom deallocation");
std::free(ptr);
}
int main() {
int* i = new int;
delete i;
// single-object delete
int* a = new int[3];
delete [] a;
// array delete
}
2
Affected subclause: 21.6.2.1
Change: operator new may throw exceptions other than std::bad_alloc.
Rationale: Consistent application of noexcept.
Effect on original feature: Valid C++ 2003 code that assumes that global operator new only throws
std::bad_alloc may execute differently in this International Standard.
C.2.10
Clause 22: diagnostics library
[diff.cpp03.diagnostics]
1
Affected subclause: 22.4
Change: Thread-local error numbers.
Rationale: Support for new thread facilities.
Effect on original feature: Valid but implementation-specific C++ 2003 code that relies on errno being
the same across threads may change behavior in this International Standard.
C.2.11
Clause 23: general utilities library
[diff.cpp03.utilities]
1
Affected subclause: 23.10.5
Change: Minimal support for garbage-collected regions.
Rationale: Required by new feature.
Effect on original feature: Valid C++ 2003 code, compiled without traceable pointer support, that
interacts with newer C++ code using regions declared reachable may have different runtime behavior.
2
Affected subclause: 23.14.5, 23.14.6, 23.14.7, 23.14.8, 23.14.9, D.9.3
Change: Standard function object types no longer derived from std::unary_function or std::binary_-
function.
Rationale: Superseded by new feature; unary_function and binary_function are no longer defined.
§ C.2.11
1292
Effect on original feature: Valid C++ 2003 code that depends on function object types being derived from
unary_function or binary_function may fail to compile in this International Standard.
C.2.12
Clause 24: strings library
[diff.cpp03.strings]
1
Affected subclause: 24.3
Change: basic_string requirements no longer allow reference-counted strings.
Rationale: Invalidation is subtly different with reference-counted strings. This change regularizes behavior
for this International Standard.
Effect on original feature: Valid C++ 2003 code may execute differently in this International Standard.
2
Affected subclause: 24.3.2.1
Change: Loosen basic_string invalidation rules.
Rationale: Allow small-string optimization.
Effect on original feature: Valid C++ 2003 code may execute differently in this International Standard.
Some const member functions, such as data and c_str, no longer invalidate iterators.
C.2.13
Clause 26: containers library
[diff.cpp03.containers]
1
Affected subclause: 26.2
Change: Complexity of size() member functions now constant.
Rationale: Lack of specification of complexity of size() resulted in divergent implementations with
inconsistent performance characteristics.
Effect on original feature: Some container implementations that conform to C++ 2003 may not conform
to the specified size() requirements in this International Standard. Adjusting containers such as std::list
to the stricter requirements may require incompatible changes.
2
Affected subclause: 26.2
Change: Requirements change: relaxation.
Rationale: Clarification.
Effect on original feature: Valid C++ 2003 code that attempts to meet the specified container requirements
may now be over-specified. Code that attempted to be portable across containers may need to be adjusted as
follows:
(2.1)
—
not all containers provide size(); use empty() instead of size() == 0;
(2.2)
—
not all containers are empty after construction (array);
(2.3)
—
not all containers have constant complexity for swap() (array).
3
Affected subclause: 26.2
Change: Requirements change: default constructible.
Rationale: Clarification of container requirements.
Effect on original feature: Valid C++ 2003 code that attempts to explicitly instantiate a container using
a user-defined type with no default constructor may fail to compile.
4
Affected subclause: 26.2.3, 26.2.6
Change: Signature changes: from void return types.
Rationale: Old signature threw away useful information that may be expensive to recalculate.
Effect on original feature: The following member functions have changed:
(4.1)
—
erase(iter) for set, multiset, map, multimap
(4.2)
—
erase(begin, end) for set, multiset, map, multimap
(4.3)
—
insert(pos, num, val) for vector, deque, list, forward_list
(4.4)
—
insert(pos, beg, end) for vector, deque, list, forward_list
Valid C++ 2003 code that relies on these functions returning void (e.g., code that creates a pointer to member
function that points to one of these functions) will fail to compile with this International Standard.
5
Affected subclause: 26.2.3, 26.2.6
Change: Signature changes: from iterator to const_iterator parameters.
Rationale: Overspecification.
Effect on original feature: The signatures of the following member functions changed from taking an
iterator to taking a const_iterator:
—
(5.1)
insert(iter, val) for vector, deque, list, set, multiset, map, multimap
§ C.2.13
1293
(5.2)
—
insert(pos, beg, end) for vector, deque, list, forward_list
(5.3)
—
erase(begin, end) for set, multiset, map, multimap
(5.4)
—
all forms of list::splice
(5.5)
—
all forms of list::merge
Valid C++ 2003 code that uses these functions may fail to compile with this International Standard.
6
Affected subclause: 26.2.3, 26.2.6
Change: Signature changes: resize.
Rationale: Performance, compatibility with move semantics.
Effect on original feature: For vector, deque, and list the fill value passed to resize is now passed by
reference instead of by value, and an additional overload of resize has been added. Valid C++ 2003 code
that uses this function may fail to compile with this International Standard.
C.2.14
Clause 28: algorithms library
[diff.cpp03.algorithms]
1
Affected subclause: 28.1
Change: Result state of inputs after application of some algorithms.
Rationale: Required by new feature.
Effect on original feature: A valid C++ 2003 program may detect that an object with a valid but
unspecified state has a different valid but unspecified state with this International Standard. For example,
std::remove and std::remove_if may leave the tail of the input sequence with a different set of values
than previously.
C.2.15
Clause 29: numerics library
[diff.cpp03.numerics]
1
Affected subclause: 29.5
Change: Specified representation of complex numbers.
Rationale: Compatibility with C99.
Effect on original feature: Valid C++ 2003 code that uses implementation-specific knowledge about the
binary representation of the required template specializations of std::complex may not be compatible with
this International Standard.
C.2.16
Clause 30: input/output library
[diff.cpp03.input.output]
1
Affected subclause: 30.7.4.1.3, 30.7.5.1.3, 30.5.5.4
Change: Specify use of explicit in existing boolean conversion functions.
Rationale: Clarify intentions, avoid workarounds.
Effect on original feature: Valid C++ 2003 code that relies on implicit boolean conversions will fail to
compile with this International Standard. Such conversions occur in the following conditions:
(1.1)
—
passing a value to a function that takes an argument of type bool;
(1.2)
—
using operator== to compare to false or true;
(1.3)
—
returning a value from a function with a return type of bool;
(1.4)
—
initializing members of type bool via aggregate initialization;
(1.5)
—
initializing a const bool& which would bind to a temporary object.
2
Affected subclause: 30.5.3.1.1
Change: Change base class of std::ios_base::failure.
Rationale: More detailed error messages.
Effect on original feature: std::ios_base::failure is no longer derived directly from std::exception,
but is now derived from std::system_error, which in turn is derived from std::runtime_error. Valid
C++ 2003 code that assumes that std::ios_base::failure is derived directly from std::exception may
execute differently in this International Standard.
3
Affected subclause: 30.5.3
Change: Flag types in std::ios_base are now bitmasks with values defined as constexpr static members.
Rationale: Required for new features.
Effect on original feature: Valid C++ 2003 code that relies on std::ios_base flag types being represented
as std::bitset or as an integer type may fail to compile with this International Standard. For example:
#include <iostream>
§ C.2.16
1294
int main() {
int flag = std::ios_base::hex;
std::cout.setf(flag);
// error: setf does not take argument of type int
}
C.3
C++ and ISO C++ 2011
[diff.cpp11]
1
This subclause lists the differences between C++ and ISO C++ 2011 (ISO/IEC 14882:2011, Programming
Languages — C++), by the chapters of this document.
C.3.1
Clause 5: lexical conventions
[diff.cpp11.lex]
1
Affected subclause: 5.9
Change: pp-number can contain one or more single quotes.
Rationale: Necessary to enable single quotes as digit separators.
Effect on original feature: Valid C++ 2011 code may fail to compile or may change meaning in this
International Standard. For example, the following code is valid both in C++ 2011 and in this International
Standard, but the macro invocation produces different outcomes because the single quotes delimit a character
literal in C++ 2011, whereas they are digit separators in this International Standard:
#define M(x, ...) __VA_ARGS__
int x[2] = { M(1’2,3’4, 5) };
// int x[2] = { 5 };
— C++ 2011
// int x[2] = { 3’4, 5 }; — this International Standard
C.3.2
Clause 6: basic concepts
[diff.cpp11.basic]
1
Affected subclause: 6.6.4.4.2
Change: New usual (non-placement) deallocator.
Rationale: Required for sized deallocation.
Effect on original feature: Valid C++ 2011 code could declare a global placement allocation function and
deallocation function as follows:
void* operator new(std::size_t, std::size_t);
void operator delete(void*, std::size_t) noexcept;
In this International Standard, however, the declaration of operator delete might match a predefined usual
(non-placement) operator delete (6.6.4.4). If so, the program is ill-formed, as it was for class member
allocation functions and deallocation functions (8.5.2.4).
C.3.3
Clause 8: expressions
[diff.cpp11.expr]
1
Affected subclause: 8.5.16
Change: A conditional expression with a throw expression as its second or third operand keeps the type
and value category of the other operand.
Rationale: Formerly mandated conversions (lvalue-to-rvalue (7.1), array-to-pointer (7.2), and function-to-
pointer (7.3) standard conversions), especially the creation of the temporary due to lvalue-to-rvalue conversion,
were considered gratuitous and surprising.
Effect on original feature: Valid C++ 2011 code that relies on the conversions may behave differently in
this International Standard:
struct S {
int x = 1;
void mf() { x = 2; }
};
int f(bool cond) {
S s;
(cond ? s : throw 0).mf();
return s.x;
}
In C++ 2011, f(true) returns 1. In this International Standard, it returns 2.
sizeof(true ? "" : throw 0)
In C++ 2011, the expression yields sizeof(const char*). In this International Standard, it yields
sizeof(const char[1]).
§ C.3.3
1295
C.3.4
Clause 10: declarations
[diff.cpp11.dcl.dcl]
1
Affected subclause: 10.1.5
Change: constexpr non-static member functions are not implicitly const member functions.
Rationale: Necessary to allow constexpr member functions to mutate the object.
Effect on original feature: Valid C++ 2011 code may fail to compile in this International Standard. For
example, the following code is valid in C++ 2011 but invalid in this International Standard because it declares
the same member function twice with different return types:
struct S {
constexpr const int &f();
int &f();
};
C.3.5
Clause 11: declarators
[diff.cpp11.dcl.decl]
1
Affected subclause: 11.6.1
Change: Classes with default member initializers can be aggregates.
Rationale: Necessary to allow default member initializers to be used by aggregate initialization.
Effect on original feature: Valid C++ 2011 code may fail to compile or may change meaning in this
International Standard.
struct S { // Aggregate in C++ 2014 onwards.
int m = 1;
};
struct X {
operator int();
operator S();
};
X a{};
S b{a};
// uses copy constructor in C++ 2011,
// performs aggregate initialization in this International Standard
C.3.6
Clause 20: library introduction
[diff.cpp11.library]
1
Affected subclause: 20.5.1.2
Change: New header.
Rationale: New functionality.
Effect on original feature: The C++ header <shared_mutex> is new. Valid C++ 2011 code that #includes
a header with that name may be invalid in this International Standard.
C.3.7
Clause 30: input/output library
[diff.cpp11.input.output]
1
Affected subclause: 30.12
Change: gets is not defined.
Rationale: Use of gets is considered dangerous.
Effect on original feature: Valid C++ 2011 code that uses the gets function may fail to compile in this
International Standard.
C.4
C++ and ISO C++ 2014
[diff.cpp14]
1
This subclause lists the differences between C++ and ISO C++ 2014 (ISO/IEC 14882:2014, Programming
Languages — C++), by the chapters of this document.
C.4.1
Clause 5: lexical conventions
[diff.cpp14.lex]
1
Affected subclause: 5.2
Change: Removal of trigraph support as a required feature.
Rationale: Prevents accidental uses of trigraphs in non-raw string literals and comments.
Effect on original feature: Valid C++ 2014 code that uses trigraphs may not be valid or may have different
semantics in this International Standard. Implementations may choose to translate trigraphs as specified in
C++ 2014 if they appear outside of a raw string literal, as part of the implementation-defined mapping from
physical source file characters to the basic source character set.
2
Affected subclause: 5.9
Change: pp-number can contain p sign and P sign.
Rationale: Necessary to enable hexadecimal floating literals.
§ C.4.1
1296
Effect on original feature: Valid C++ 2014 code may fail to compile or produce different results in this
International Standard. Specifically, character sequences like 0p+0 and 0e1_p+0 are three separate tokens
each in C++ 2014, but one single token in this International Standard.
#define F(a) b ## a
int b0p = F(0p+0);
// ill-formed; equivalent to “int b0p = b0p + 0;” in C++ 2014
C.4.2
Clause 8: expressions
[diff.cpp14.expr]
1
Affected subclause: 8.5.1.6, 8.5.2.2
Change: Remove increment operator with bool operand.
Rationale: Obsolete feature with occasionally surprising semantics.
Effect on original feature: A valid C++ 2014 expression utilizing the increment operator on a bool lvalue
is ill-formed in this International Standard. Note that this might occur when the lvalue has a type given by a
template parameter.
2
Affected subclause: 8.5.2.4, 8.5.2.5
Change: Dynamic allocation mechanism for over-aligned types.
Rationale: Simplify use of over-aligned types.
Effect on original feature: In C++ 2014 code that uses a new-expression to allocate an object with an over-
aligned class type, where that class has no allocation functions of its own, ::operator new(std::size_t) is
used to allocate the memory. In this International Standard, ::operator new(std::size_t, std::align_-
val_t) is used instead.
C.4.3
Clause 10: declarations
[diff.cpp14.dcl.dcl]
1
Affected subclause: 10.1.1
Change: Removal of register storage-class-specifier.
Rationale: Enable repurposing of deprecated keyword in future revisions of this International Standard.
Effect on original feature: A valid C++ 2014 declaration utilizing the register storage-class-specifier is
ill-formed in this International Standard. The specifier can simply be removed to retain the original meaning.
2
Affected subclause: 10.1.7.4
Change: auto deduction from braced-init-list.
Rationale: More intuitive deduction behavior.
Effect on original feature: Valid C++ 2014 code may fail to compile or may change meaning in this
International Standard. For example:
auto x1{1};
// was std::initializer_list<int>, now int
auto x2{1, 2}; // was std::initializer_list<int>, now ill-formed
C.4.4
Clause 11: declarators
[diff.cpp14.decl]
1
Affected subclause: 11.3.5
Change: Make exception specifications be part of the type system.
Rationale: Improve type-safety.
Effect on original feature: Valid C++ 2014 code may fail to compile or change meaning in this International
Standard:
void g1() noexcept;
void g2();
template<class T> int f(T *, T *);
int x = f(g1, g2);
// ill-formed; previously well-formed
2
Affected subclause: 11.6.1
Change: Definition of an aggregate is extended to apply to user-defined types with base classes.
Rationale: To increase convenience of aggregate initialization.
Effect on original feature: Valid C++ 2014 code may fail to compile or produce different results in this
International Standard; initialization from an empty initializer list will perform aggregate initialization
instead of invoking a default constructor for the affected types:
struct derived;
struct base {
friend struct derived;
private:
base();
};
§ C.4.4
1297
struct derived : base {};
derived d1{};
// error; the code was well-formed in C++ 2014
derived d2;
// still OK
C.4.5
Clause 15: special member functions
[diff.cpp14.special]
1
Affected subclause: 15.6.3
Change: Inheriting a constructor no longer injects a constructor into the derived class.
Rationale: Better interaction with other language features.
Effect on original feature: Valid C++ 2014 code that uses inheriting constructors may not be valid or
may have different semantics. A using-declaration that names a constructor now makes the corresponding
base class constructors visible to initializations of the derived class rather than declaring additional derived
class constructors.
struct A {
template<typename T> A(T, typename T::type = 0);
A(int);
};
struct B : A {
using A::A;
B(int);
};
B b(42L); // now calls B(int), used to call B<long>(long),
// which called A(int) due to substitution failure
// in A<long>(long).
C.4.6
Clause 17: templates
[diff.cpp14.temp]
1
Affected subclause: 17.9.2.5
Change: Allowance to deduce from the type of a non-type template argument.
Rationale: In combination with the ability to declare non-type template arguments with placeholder types,
allows partial specializations to decompose from the type deduced for the non-type template argument.
Effect on original feature: Valid C++ 2014 code may fail to compile or produce different results in this
International Standard:
template <int N> struct A;
template <typename T, T N> int foo(A<N> *) = delete;
void foo(void *);
void bar(A<0> *p) {
foo(p); // ill-formed; previously well-formed
}
C.4.7
Clause 18: exception handling
[diff.cpp14.except]
1
Affected subclause: 18.4
Change: Remove dynamic exception specifications.
Rationale: Dynamic exception specifications were a deprecated feature that was complex and brittle in
use. They interacted badly with the type system, which became a more significant issue in this International
Standard where (non-dynamic) exception specifications are part of the function type.
Effect on original feature: A valid C++ 2014 function declaration, member function declaration, function
pointer declaration, or function reference declaration, if it has a potentially throwing dynamic exception
specification, will be rejected as ill-formed in this International Standard. Violating a non-throwing dynamic
exception specification will call terminate rather than unexpected and might not perform stack unwinding
prior to such a call.
C.4.8
Clause 20: library introduction
[diff.cpp14.library]
1
Affected subclause: 20.5.1.2
Change: New headers.
Rationale: New functionality.
Effect on original feature: The following C++ headers are new: <any>, <execution>, <filesystem>,
<memory_resource>, <optional>, <string_view>, and <variant>. Valid C++ 2014 code that #includes
headers with these names may be invalid in this International Standard.
§ C.4.8
1298
2
Affected subclause: 20.5.4.2.3
Change: New reserved namespaces.
Rationale: Reserve namespaces for future revisions of the standard library that might otherwise be
incompatible with existing programs.
Effect on original feature: The global namespaces std followed by an arbitrary sequence of digits is
reserved for future standardization. Valid C++ 2014 code that uses such a top-level namespace, e.g., std2,
may be invalid in this International Standard.
C.4.9
Clause 23: general utilities library
[diff.cpp14.utilities]
1
Affected subclause: 23.14.13
Change: Constructors taking allocators removed.
Rationale: No implementation consensus.
Effect on original feature: Valid C++ 2014 code may fail to compile or may change meaning in this
International Standard. Specifically, constructing a std::function with an allocator is ill-formed and
uses-allocator construction will not pass an allocator to std::function constructors in this International
Standard.
2
Affected subclause: 23.11.3
Change: Different constraint on conversions from unique_ptr.
Rationale: Adding array support to shared_ptr, via the syntax shared_ptr<T[]> and shared_ptr<T[N]>.
Effect on original feature: Valid C++ 2014 code may fail to compile or may change meaning in this
International Standard. For example:
#include <memory>
std::unique_ptr<int[]> arr(new int[1]);
std::shared_ptr<int> ptr(std::move(arr)); // error: int(*)[] is not compatible with int*
C.4.10
Clause 24: strings library
[diff.cpp14.string]
1
Affected subclause: 24.3.2
Change: Non-const .data() member added.
Rationale: The lack of a non-const .data() differed from the similar member of std::vector. This change
regularizes behavior for this International Standard.
Effect on original feature: Overloaded functions which have differing code paths for char* and const
char* arguments will execute differently when called with a non-const string’s .data() member in this
International Standard.
int f(char *) = delete;
int f(const char *);
string s;
int x = f(s.data()); // ill-formed; previously well-formed
C.4.11
Clause 26: containers library
[diff.cpp14.containers]
1
Affected subclause: 26.2.6
Change: Requirements change:
Rationale: Increase portability, clarification of associative container requirements.
Effect on original feature: Valid C++ 2014 code that attempts to use associative containers having a
comparison object with non-const function call operator may fail to compile in this International Standard:
#include <set>
struct compare
{
bool operator()(int a, int b)
{
return a < b;
}
};
int main() {
const std::set<int, compare> s;
s.find(0);
}
§ C.4.11
1299
C.4.12
Annex D: compatibility features
[diff.cpp14.depr]
Change: The class templates auto_ptr, unary_function, and binary_function, the function templates
random_shuffle, and the function templates (and their return types) ptr_fun, mem_fun, mem_fun_ref,
bind1st, and bind2nd are not defined.
Rationale: Superseded by new features.
Effect on original feature: Valid C++ 2014 code that uses these class templates and function templates
may fail to compile in this International Standard.
Change: Remove old iostreams members [depr.ios.members].
Rationale: Redundant feature for compatibility with pre-standard code has served its time.
Effect on original feature: A valid C++ 2014 program using these identifiers may be ill-formed in this
International Standard.
C.5
C++ and ISO C++ 2017
[diff.cpp17]
1
This subclause lists the differences between C++ and ISO C++ 2017 (ISO/IEC 14882:2017, Programming
Languages — C++), by the chapters of this document.
C.5.1
Clause 5: lexical conventions
[diff.cpp17.lex]
1
Affected subclause: 5.11
Change: New keywords.
Rationale: Required for new features. The requires keyword is added to introduce constraints through
a requires-clause or a requires-expression. The concept keyword is added to enable the definition of
concepts (17.6.8).
Effect on original feature: Valid ISO C++ 2017 code using concept or requires as an identifier is not
valid in this International Standard.
2
Affected subclause: 5.12
Change: New operator <=>.
Rationale: Necessary for new functionality.
Effect on original feature: Valid C++ 2017 code that contains a <= token immediately followed by a >
token may be ill-formed or have different semantics in this International Standard:
namespace N {
struct X {};
bool operator<=(X, X);
template<bool(X, X)> struct Y {};
Y<operator<=> y;
// ill-formed; previously well-formed
}
C.5.2
Clause 8: expressions
[diff.cpp17.expr]
1
Affected subclause: 8.4.5.2
Change: Implicit lambda capture may capture additional entities.
Rationale: Rule simplification, necessary to resolve interactions with constexpr if.
Effect on original feature: Lambdas with a capture-default may capture local entities that were not
captured in C++ 2017 if those entities are only referenced in contexts that do not result in an odr-use.
C.5.3
Clause 17: templates
[diff.cpp17.temp]
1
Affected subclause: 17.2
Change: An unqualified-id that is followed by a < and for which name lookup finds nothing or finds a
function will be treated as a template-name in order to potentially cause argument dependent lookup to be
performed.
Rationale: It was problematic to call a function template with an explicit template argument list via
argument dependent lookup because of the need to have a template with the same name visible via normal
lookup.
Effect on original feature: Previously valid code that uses a function name as the left operand of a <
operator would become ill-formed.
struct A {};
bool operator<(void (*fp)(), A);
§ C.5.3
1300
void f() {}
int main() {
A a;
f < a;
// ill-formed; previously well-formed
(f) < a;
// still well formed
}
C.5.4
Clause 20: library introduction
[diff.cpp17.library]
20.5.1.2
Change: New headers.
Rationale: New functionality.
Effect on original feature: The following C++ headers are new: <compare> and <syncstream>. Valid
C++ 2017 code that #includes headers with these names may be invalid in this International Standard.
C.6
C standard library
[diff.library]
1
This subclause summarizes the explicit changes in headers, definitions, declarations, or behavior between the
C standard library in the C standard and the parts of the C++ standard library that were included from the
C standard library.
C.6.1
Modifications to headers
[diff.mods.to.headers]
1
For compatibility with the C standard library, the C++ standard library provides the C headers enumerated
in D.5, but their use is deprecated in C++.
2
There are no C++ headers for the C headers <stdatomic.h>, <stdnoreturn.h>, and <threads.h>, nor are
the C headers themselves part of C++.
3
The C++ headers <ccomplex> (D.4.1) and <ctgmath> (D.4.4), as well as their corresponding C headers
<complex.h> and <tgmath.h>, do not contain any of the content from the C standard library and instead
merely include other headers from the C++ standard library.
4
The headers <ciso646>, <cstdalign> (D.4.2), and <cstdbool> (D.4.3) are meaningless in C++. Use of the
C++ headers <ccomplex>, <cstdalign>, <cstdbool>, and <ctgmath> is deprecated (D.5).
C.6.2
Modifications to definitions
[diff.mods.to.definitions]
C.6.2.1
Types char16_t and char32_t
[diff.char16]
1
The types char16_t and char32_t are distinct types rather than typedefs to existing integral types. The
tokens char16_t and char32_t are keywords in this International Standard (5.11). They do not appear as
macro names defined in <cuchar> (24.5.5).
C.6.2.2
Type wchar_t
[diff.wchar.t]
1
The type wchar_t is a distinct type rather than a typedef to an existing integral type. The token wchar_t
is a keyword in this International Standard (5.11). It does not appear as a type name defined in any of
<cstddef> (21.2.1), <cstdlib> (21.2.2), or <cwchar> (24.5.4).
C.6.2.3
Header <assert.h>
[diff.header.assert.h]
1
The token static_assert is a keyword in this International Standard (5.11). It does not appear as a macro
name defined in <cassert> (22.3.1).
C.6.2.4
Header <iso646.h>
[diff.header.iso646.h]
1
The tokens and, and_eq, bitand, bitor, compl, not_eq, not, or, or_eq, xor, and xor_eq are keywords in
this International Standard (5.11). They do not appear as macro names defined in <ciso646>.
C.6.2.5
Header <stdalign.h>
[diff.header.stdalign.h]
1
The token alignas is a keyword in this International Standard (5.11). It does not appear as a macro name
defined in <cstdalign> (D.4.2).
C.6.2.6
Header <stdbool.h>
[diff.header.stdbool.h]
1
The tokens bool, true, and false are keywords in this International Standard (5.11). They do not appear
as macro names defined in <cstdbool> (D.4.3).
§ C.6.2.6
1301
C.6.2.7
Macro NULL
[diff.null]
1
The macro NULL, defined in any of <clocale> (25.5), <cstddef> (21.2.1), <cstdio> (30.12.1), <cstdlib>
(21.2.2), <cstring> (24.5.3), <ctime> (23.17.8), or <cwchar> (24.5.4), is an implementation-defined C++ null
pointer constant in this International Standard (21.2).
C.6.3
Modifications to declarations
[diff.mods.to.declarations]
1
Header <cstring> (24.5.3): The following functions have different declarations:
(1.1)
—
strchr
(1.2)
—
strpbrk
(1.3)
—
strrchr
(1.4)
—
strstr
(1.5)
—
memchr
Subclause 24.5.3 describes the changes.
2
Header <cwchar> (24.5.4): The following functions have different declarations:
(2.1)
—
wcschr
(2.2)
—
wcspbrk
(2.3)
—
wcsrchr
(2.4)
—
wcsstr
(2.5)
—
wmemchr
Subclause 24.5.4 describes the changes.
3
Header <cstddef> (21.2.1) declares the name nullptr_t in addition to the names declared in <stddef.h>
in the C standard library.
C.6.4
Modifications to behavior
[diff.mods.to.behavior]
1
Header <cstdlib> (21.2.2): The following functions have different behavior:
(1.1)
—
atexit
(1.2)
—
exit
(1.3)
—
abort
Subclause 21.5 describes the changes.
2
Header <csetjmp> (21.11.2): The following functions have different behavior:
(2.1)
—
longjmp
Subclause 21.11.2 describes the changes.
C.6.4.1
Macro offsetof(type, member-designator )
[diff.offsetof]
1
The macro offsetof, defined in <cstddef> (21.2.1), accepts a restricted set of type arguments in this
International Standard. Subclause 21.2.4 describes the change.
C.6.4.2
Memory allocation functions
[diff.malloc]
1
The functions aligned_alloc, calloc, malloc, and realloc are restricted in this International Standard.
Subclause 23.10.12 describes the changes.
§ C.6.4.2
1302
Annex D
(normative)
Compatibility features
[depr]
1
This Clause describes features of the C++ Standard that are specified for compatibility with existing
implementations.
2
These are deprecated features, where deprecated is defined as: Normative for the current edition of this
International Standard, but having been identified as a candidate for removal from future revisions. An
implementation may declare library names and entities described in this Clause with the deprecated
attribute (10.6.4).
D.1
Redeclaration of static constexpr data members
[depr.static_constexpr]
1
For compatibility with prior C++ International Standards, a constexpr static data member may be redun-
dantly redeclared outside the class with no initializer. This usage is deprecated. [ Example:
struct A {
static constexpr int n = 5;
// definition (declaration in C++ 2014)
};
constexpr int A::n;
// redundant declaration (definition in C++ 2014)
— end example ]
D.2
Implicit declaration of copy functions
[depr.impldec]
1
The implicit definition of a copy constructor as defaulted is deprecated if the class has a user-declared copy
assignment operator or a user-declared destructor. The implicit definition of a copy assignment operator as
defaulted is deprecated if the class has a user-declared copy constructor or a user-declared destructor (15.4,
15.8). In a future revision of this International Standard, these implicit definitions could become deleted (11.4).
D.3
Deprecated exception specifications
[depr.except.spec]
1
The noexcept-specifier throw() is deprecated.
D.4
C++ standard library headers
[depr.cpp.headers]
1
For compatibility with prior C++ International Standards, the C++ standard library provides headers
<ccomplex> (D.4.1), <cstdalign> (D.4.2), <cstdbool> (D.4.3), and <ctgmath> (D.4.4). The use of these
headers is deprecated.
D.4.1
Header <ccomplex> synopsis
[depr.ccomplex.syn]
#include <complex>
1
The header <ccomplex> behaves as if it simply includes the header <complex> (29.5.1).
D.4.2
Header <cstdalign> synopsis
[depr.cstdalign.syn]
#define __alignas_is_defined 1
1
The contents of the header <cstdalign> are the same as the C standard library header <stdalign.h>, with
the following changes: The header <cstdalign> and the header <stdalign.h> shall not define a macro
named alignas.
See also: ISO C 7.15
D.4.3
Header <cstdbool> synopsis
[depr.cstdbool.syn]
#define __bool_true_false_are_defined 1
1
The contents of the header <cstdbool> are the same as the C standard library header <stdbool.h>, with
the following changes: The header <cstdbool> and the header <stdbool.h> shall not define macros named
bool, true, or false.
See also: ISO C 7.18
§ D.4.3
1303
D.4.4
Header <ctgmath> synopsis
[depr.ctgmath.syn]
#include <complex>
#include <cmath>
1
The header <ctgmath> simply includes the headers <complex> (29.5.1) and <cmath> (29.9.1).
2
[ Note: The overloads provided in C by type-generic macros are already provided in <complex> and <cmath>
by “sufficient” additional overloads. — end note ]
D.5
C standard library headers
[depr.c.headers]
1
For compatibility with the C standard library, the C++ standard library provides the C headers shown in
Table 141.
Table 141 — C headers
<assert.h>
<inttypes.h>
<signal.h>
<stdio.h>
<wchar.h>
<complex.h>
<iso646.h>
<stdalign.h>
<stdlib.h>
<wctype.h>
<ctype.h>
<limits.h>
<stdarg.h>
<string.h>
<errno.h>
<locale.h>
<stdbool.h>
<tgmath.h>
<fenv.h>
<math.h>
<stddef.h>
<time.h>
<float.h>
<setjmp.h>
<stdint.h>
<uchar.h>
2
The header <complex.h> behaves as if it simply includes the header <ccomplex>. The header <tgmath.h>
behaves as if it simply includes the header <ctgmath>.
3
Every other C header, each of which has a name of the form name.h, behaves as if each name placed in the
standard library namespace by the corresponding cname header is placed within the global namespace scope,
except for the functions described in 29.9.5, the declaration of std::byte (21.2.1), and the functions and
function templates described in 21.2.5. It is unspecified whether these names are first declared or defined
within namespace scope (6.3.6) of the namespace std and are then injected into the global namespace scope
by explicit using-declarations (10.3.3).
4
[ Example: The header <cstdlib> assuredly provides its declarations and definitions within the namespace
std. It may also provide these names within the global namespace. The header <stdlib.h> assuredly
provides the same declarations and definitions within the global namespace, much as in the C Standard. It
may also provide these names within the namespace std.
— end example ]
D.6
Relational operators
[depr.relops]
1
The header <utility> has the following additions:
namespace std::rel_ops {
template<class T> bool operator!=(const T&, const T&);
template<class T> bool operator> (const T&, const T&);
template<class T> bool operator<=(const T&, const T&);
template<class T> bool operator>=(const T&, const T&);
}
2
To avoid redundant definitions of operator!= out of operator== and operators >,
<=, and >= out of
operator<, the library provides the following:
template<class T> bool operator!=(const T& x, const T& y);
3
Requires: Type T is EqualityComparable (Table 20).
4
Returns: !(x == y).
template<class T> bool operator>(const T& x, const T& y);
5
Requires: Type T is LessThanComparable (Table 21).
6
Returns: y < x.
template<class T> bool operator<=(const T& x, const T& y);
7
Requires: Type T is LessThanComparable (Table 21).
8
Returns: !(y < x).
§ D.6
1304
template<class T> bool operator>=(const T& x, const T& y);
9
Requires: Type T is LessThanComparable (Table 21).
10
Returns: !(x < y).
D.7
char* streams
[depr.str.strstreams]
1
The header <strstream> defines three types that associate stream buffers with character array objects and
assist reading and writing such objects.
D.7.1
Class strstreambuf
[depr.strstreambuf]
namespace std {
class strstreambuf : public basic_streambuf<char> {
public:
explicit strstreambuf(streamsize alsize_arg = 0);
strstreambuf(void* (*palloc_arg)(size_t), void (*pfree_arg)(void*));
strstreambuf(char* gnext_arg, streamsize n, char* pbeg_arg =
nullptr);
strstreambuf(const char* gnext_arg, streamsize n);
strstreambuf(signed char* gnext_arg, streamsize n,
signed char* pbeg_arg = nullptr);
strstreambuf(const signed char* gnext_arg, streamsize n);
strstreambuf(unsigned char* gnext_arg, streamsize n,
unsigned char* pbeg_arg = nullptr);
strstreambuf(const unsigned char* gnext_arg, streamsize n);
virtual ~strstreambuf();
void freeze(bool freezefl = true);
char* str();
int pcount();
protected:
int_type overflow (int_type c = EOF) override;
int_type pbackfail(int_type c = EOF) override;
int_type underflow() override;
pos_type seekoff(off_type off, ios_base::seekdir way,
ios_base::openmode which
= ios_base::in | ios_base::out) override;
pos_type seekpos(pos_type sp,
ios_base::openmode which
= ios_base::in | ios_base::out) override;
streambuf* setbuf(char* s, streamsize n) override;
private:
using strstate = T1;
// exposition only
static const strstate allocated;
// exposition only
static const strstate constant;
// exposition only
static const strstate dynamic;
// exposition only
static const strstate frozen;
// exposition only
strstate strmode;
// exposition only
streamsize alsize;
// exposition only
void* (*palloc)(size_t);
// exposition only
void (*pfree)(void*);
// exposition only
};
}
1
The class strstreambuf associates the input sequence, and possibly the output sequence, with an object of
some character array type, whose elements store arbitrary values. The array object has several attributes.
2
[ Note: For the sake of exposition, these are represented as elements of a bitmask type (indicated here as T1)
called strstate. The elements are:
(2.1)
—
allocated, set when a dynamic array object has been allocated, and hence should be freed by the
destructor for the strstreambuf object;
§ D.7.1
1305
(2.2)
—
constant, set when the array object has const elements, so the output sequence cannot be written;
(2.3)
—
dynamic, set when the array object is allocated (or reallocated) as necessary to hold a character sequence
that can change in length;
(2.4)
—
frozen, set when the program has requested that the array object not be altered, reallocated, or freed.
— end note ]
3
[ Note: For the sake of exposition, the maintained data is presented here as:
(3.1)
—
strstate strmode, the attributes of the array object associated with the strstreambuf object;
(3.2)
—
int alsize, the suggested minimum size for a dynamic array object;
(3.3)
—
void* (*palloc)(size_t), points to the function to call to allocate a dynamic array object;
(3.4)
—
void (*pfree)(void*), points to the function to call to free a dynamic array object.
— end note ]
4
Each object of class strstreambuf has a seekable area, delimited by the pointers seeklow and seekhigh. If
gnext is a null pointer, the seekable area is undefined. Otherwise, seeklow equals gbeg and seekhigh is
either pend, if pend is not a null pointer, or gend.
D.7.1.1
strstreambuf constructors
[depr.strstreambuf.cons]
explicit strstreambuf(streamsize alsize_arg = 0);
1
Effects: Constructs an object of class strstreambuf, initializing the base class with streambuf(). The
postconditions of this function are indicated in Table 142.
Table 142 — strstreambuf(streamsize) effects
Element
Value
strmode dynamic
alsize
alsize_arg
palloc
a null pointer
pfree
a null pointer
strstreambuf(void* (*palloc_arg)(size_t), void (*pfree_arg)(void*));
2
Effects: Constructs an object of class strstreambuf, initializing the base class with streambuf(). The
postconditions of this function are indicated in Table 143.
Table 143 — strstreambuf(void* (*)(size_t), void (*)(void*)) effects
Element
Value
strmode dynamic
alsize
an unspecified value
palloc
palloc_arg
pfree
pfree_arg
strstreambuf(char* gnext_arg, streamsize n, char* pbeg_arg = nullptr);
strstreambuf(signed char* gnext_arg, streamsize n,
signed char* pbeg_arg = nullptr);
strstreambuf(unsigned char* gnext_arg, streamsize n,
unsigned char* pbeg_arg = nullptr);
3
Effects: Constructs an object of class strstreambuf, initializing the base class with streambuf(). The
postconditions of this function are indicated in Table 144.
4
gnext_arg shall point to the first element of an array object whose number of elements N is determined
as follows:
(4.1)
—
If n
> 0, N is n.
(4.2)
—
If n
== 0, N is std::strlen(gnext_arg).
§ D.7.1.1
1306
Table 144 — strstreambuf(charT*, streamsize, charT*) effects
Element
Value
strmode
0
alsize
an unspecified value
palloc
a null pointer
pfree
a null pointer
(4.3)
—
If n
< 0, N is INT_MAX.334
5
If pbeg_arg is a null pointer, the function executes:
setg(gnext_arg, gnext_arg, gnext_arg + N);
6
Otherwise, the function executes:
setg(gnext_arg, gnext_arg, pbeg_arg);
setp(pbeg_arg, pbeg_arg + N);
strstreambuf(const char* gnext_arg, streamsize n);
strstreambuf(const signed char* gnext_arg, streamsize n);
strstreambuf(const unsigned char* gnext_arg, streamsize n);
7
Effects: Behaves the same as strstreambuf((char*)gnext_arg,n), except that the constructor also
sets constant in strmode.
virtual ~strstreambuf();
8
Effects: Destroys an object of class strstreambuf. The function frees the dynamically allocated array
object only if (strmode & allocated) != 0 and (strmode & frozen) == 0. (D.7.1.3 describes how
a dynamically allocated array object is freed.)
D.7.1.2
Member functions
[depr.strstreambuf.members]
void freeze(bool freezefl = true);
1
Effects: If strmode & dynamic is nonzero, alters the freeze status of the dynamic array object as
follows:
(1.1)
—
If freezefl is true, the function sets frozen in strmode.
(1.2)
—
Otherwise, it clears frozen in strmode.
char* str();
2
Effects: Calls freeze(), then returns the beginning pointer for the input sequence, gbeg.
3
Remarks: The return value can be a null pointer.
int pcount() const;
4
Effects: If the next pointer for the output sequence, pnext, is a null pointer, returns zero. Otherwise,
returns the current effective length of the array object as the next pointer minus the beginning pointer
for the output sequence, pnext - pbeg.
D.7.1.3
strstreambuf overridden virtual functions
[depr.strstreambuf.virtuals]
int_type overflow(int_type c = EOF) override;
1
Effects: Appends the character designated by c to the output sequence, if possible, in one of two ways:
(1.1)
—
If c
!= EOF and if either the output sequence has a write position available or the function makes
a write position available (as described below), assigns c to *pnext++.
Returns (unsigned char)c.
(1.2)
—
If c
== EOF, there is no character to append.
Returns a value other than EOF.
334) The function signature strlen(const char*) is declared in <cstring> (24.5.3). The macro INT_MAX is defined in <climits>
(21.3.5).
§ D.7.1.3
1307
2
Returns EOF to indicate failure.
3
Remarks: The function can alter the number of write positions available as a result of any call.
4
To make a write position available, the function reallocates (or initially allocates) an array object with
a sufficient number of elements n to hold the current array object (if any), plus at least one additional
write position. How many additional write positions are made available is otherwise unspecified.335 If
palloc is not a null pointer, the function calls (*palloc)(n) to allocate the new dynamic array object.
Otherwise, it evaluates the expression new charT[n]. In either case, if the allocation fails, the function
returns EOF. Otherwise, it sets allocated in strmode.
5
To free a previously existing dynamic array object whose first element address is p: If pfree is not a
null pointer, the function calls (*pfree)(p). Otherwise, it evaluates the expression delete[]p.
6
If (strmode & dynamic) == 0, or if (strmode & frozen) != 0, the function cannot extend the array
(reallocate it with greater length) to make a write position available.
int_type pbackfail(int_type c = EOF) override;
7
Puts back the character designated by c to the input sequence, if possible, in one of three ways:
(7.1)
—
If c
!= EOF, if the input sequence has a putback position available, and if (char)c == gnext[-1],
assigns gnext - 1 to gnext.
Returns c.
(7.2)
—
If c
!= EOF, if the input sequence has a putback position available, and if strmode & constant
is zero, assigns c to *--gnext.
Returns c.
(7.3)
—
If c
== EOF and if the input sequence has a putback position available, assigns gnext - 1 to
gnext.
Returns a value other than EOF.
8
Returns EOF to indicate failure.
9
Remarks: If the function can succeed in more than one of these ways, it is unspecified which way is
chosen. The function can alter the number of putback positions available as a result of any call.
int_type underflow() override;
10
Effects: Reads a character from the input sequence, if possible, without moving the stream position
past it, as follows:
(10.1)
—
If the input sequence has a read position available, the function signals success by returning
(unsigned char)*gnext.
(10.2)
—
Otherwise, if the current write next pointer pnext is not a null pointer and is greater than the
current read end pointer gend, makes a read position available by assigning to gend a value greater
than gnext and no greater than pnext.
Returns (unsigned char)*gnext.
11
Returns EOF to indicate failure.
12
Remarks: The function can alter the number of read positions available as a result of any call.
pos_type seekoff(off_type off, seekdir way, openmode which = in | out) override;
13
Effects: Alters the stream position within one of the controlled sequences, if possible, as indicated in
Table 145.
14
For a sequence to be positioned, if its next pointer is a null pointer, the positioning operation fails.
Otherwise, the function determines newoff as indicated in Table 146.
15
If (newoff + off) < (seeklow - xbeg) or (seekhigh - xbeg) < (newoff + off), the positioning
operation fails. Otherwise, the function assigns xbeg + newoff + off to the next pointer xnext.
16
Returns: pos_type(newoff), constructed from the resultant offset newoff (of type off_type), that
stores the resultant stream position, if possible. If the positioning operation fails, or if the constructed
object cannot represent the resultant stream position, the return value is pos_type(off_type(-1)).
335) An implementation should consider alsize in making this decision.
§ D.7.1.3
1308
Table 145 — seekoff positioning
Conditions
Result
(which & ios::in) != 0
positions the input sequence
(which & ios::out) != 0
positions the output sequence
(which & (ios::in |
positions both the input and the output sequences
ios::out)) == (ios::in |
ios::out)) and
way == either
ios::beg or
ios::end
Otherwise
the positioning operation fails.
Table 146 — newoff values
Condition
newoff Value
way == ios::beg
0
way == ios::cur
the next pointer minus the begin-
ning pointer (xnext - xbeg).
way == ios::end
seekhigh minus the beginning
pointer (seekhigh - xbeg).
pos_type seekpos(pos_type sp, ios_base::openmode which
= ios_base::in | ios_base::out) override;
17
Effects: Alters the stream position within one of the controlled sequences, if possible, to correspond to
the stream position stored in sp (as described below).
(17.1)
—
If (which & ios::in) != 0, positions the input sequence.
(17.2)
—
If (which & ios::out) != 0, positions the output sequence.
(17.3)
—
If the function positions neither sequence, the positioning operation fails.
18
For a sequence to be positioned, if its next pointer is a null pointer, the positioning operation fails.
Otherwise, the function determines newoff from sp.offset():
(18.1)
—
If newoff is an invalid stream position, has a negative value, or has a value greater than (seekhigh
- seeklow), the positioning operation fails
(18.2)
—
Otherwise, the function adds newoff to the beginning pointer xbeg and stores the result in the
next pointer xnext.
19
Returns: pos_type(newoff), constructed from the resultant offset newoff (of type off_type), that
stores the resultant stream position, if possible. If the positioning operation fails, or if the constructed
object cannot represent the resultant stream position, the return value is pos_type(off_type(-1)).
streambuf<char>* setbuf(char* s, streamsize n) override;
20
Effects: Implementation defined, except that setbuf(0, 0) has no effect.
D.7.2
Class istrstream
[depr.istrstream]
namespace std {
class istrstream : public basic_istream<char> {
public:
explicit istrstream(const char* s);
explicit istrstream(char* s);
istrstream(const char* s, streamsize n);
istrstream(char* s, streamsize n);
virtual ~istrstream();
strstreambuf* rdbuf() const;
char* str();
§ D.7.2
1309
private:
strstreambuf sb;
// exposition only
};
}
1
The class istrstream supports the reading of objects of class strstreambuf. It supplies a strstreambuf
object to control the associated array object. For the sake of exposition, the maintained data is presented
here as:
(1.1)
—
sb, the strstreambuf object.
D.7.2.1
istrstream constructors
[depr.istrstream.cons]
explicit istrstream(const char* s);
explicit istrstream(char* s);
1
Effects: Constructs an object of class istrstream, initializing the base class with istream(&sb) and
initializing sb with strstreambuf(s,0). s shall designate the first element of an ntbs.
istrstream(const char* s, streamsize n);
istrstream(char* s, streamsize n);
2
Effects: Constructs an object of class istrstream, initializing the base class with istream(&sb) and
initializing sb with strstreambuf(s,n). s shall designate the first element of an array whose length is
n elements, and n shall be greater than zero.
D.7.2.2
Member functions
[depr.istrstream.members]
strstreambuf* rdbuf() const;
1
Returns: const_cast<strstreambuf*>(&sb).
char* str();
2
Returns: rdbuf()->str().
D.7.3
Class ostrstream
[depr.ostrstream]
namespace std {
class ostrstream : public basic_ostream<char> {
public:
ostrstream();
ostrstream(char* s, int n, ios_base::openmode mode = ios_base::out);
virtual ~ostrstream();
strstreambuf* rdbuf() const;
void freeze(bool freezefl = true);
char* str();
int pcount() const;
private:
strstreambuf sb;
// exposition only
};
}
1
The class ostrstream supports the writing of objects of class strstreambuf. It supplies a strstreambuf
object to control the associated array object. For the sake of exposition, the maintained data is presented
here as:
(1.1)
—
sb, the strstreambuf object.
D.7.3.1
ostrstream constructors
[depr.ostrstream.cons]
ostrstream();
1
Effects: Constructs an object of class ostrstream, initializing the base class with ostream(&sb) and
initializing sb with strstreambuf().
§ D.7.3.1
1310
ostrstream(char* s, int n, ios_base::openmode mode = ios_base::out);
2
Effects: Constructs an object of class ostrstream, initializing the base class with ostream(&sb), and
initializing sb with one of two constructors:
(2.1)
—
If (mode & app) == 0, then s shall designate the first element of an array of n elements.
The constructor is strstreambuf(s, n, s).
(2.2)
—
If
(mode & app) != 0, then s shall designate the first element of an array of n elements that
contains an ntbs whose first element is designated by s. The constructor is strstreambuf(s, n,
s + std::strlen(s)).336
D.7.3.2
Member functions
[depr.ostrstream.members]
strstreambuf* rdbuf() const;
1
Returns: (strstreambuf*)&sb.
void freeze(bool freezefl = true);
2
Effects: Calls rdbuf()->freeze(freezefl).
char* str();
3
Returns: rdbuf()->str().
int pcount() const;
4
Returns: rdbuf()->pcount().
D.7.4
Class strstream
[depr.strstream]
namespace std {
class strstream
: public basic_iostream<char> {
public:
// types
using char_type = char;
using int_type
= char_traits<char>::int_type;
using pos_type
= char_traits<char>::pos_type;
using off_type
= char_traits<char>::off_type;
// constructors/destructor
strstream();
strstream(char* s, int n,
ios_base::openmode mode = ios_base::in|ios_base::out);
virtual ~strstream();
// members
strstreambuf* rdbuf() const;
void freeze(bool freezefl = true);
int pcount() const;
char* str();
private:
strstreambuf sb;
// exposition only
};
}
1
The class strstream supports reading and writing from objects of class strstreambuf. It supplies a
strstreambuf object to control the associated array object. For the sake of exposition, the maintained data
is presented here as:
(1.1)
—
sb, the strstreambuf object.
336) The function signature strlen(const char*) is declared in <cstring> (24.5.3).
§ D.7.4
1311