[diff.iso] - C++20 → C++23

Files changed (1) hide show

tmp/tmpj1sj6jcc/{from.md → to.md} +80 -75

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

@@ -1,9 +1,11 @@
 ## C++ and ISO C <a id="diff.iso">[[diff.iso]]</a>
-This subclause lists the differences between C++ and ISO C, in addition
-to those listed above, by the chapters of this document.
 ###  [[lex]]: lexical conventions <a id="diff.lex">[[diff.lex]]</a>
 **Change:** New Keywords
 New keywords are added to C++; see [[lex.key]]. **Rationale:** These
@@ -34,10 +36,16 @@ sizeof('x') == sizeof(int)
 ```
 will not work the same as C++ programs. Simple. Programs which depend
 upon `sizeof('x')` are probably rare.
 **Change:** String literals made const.
 The type of a *string-literal* is changed from “array of `char`” to
 “array of `const char`”. The type of a UTF-8 string literal is changed
 from “array of `char`” to “array of `const char8_t`”. The type of a
 UTF-16 string literal is changed from “array of *some-integer-type*” to
@@ -51,13 +59,13 @@ Change to semantics of well-defined feature. Syntactic transformation.
 The fix is to add a cast:
 ``` cpp
 char* p = "abc";                // valid in C, invalid in C++{}
 void f(char*) {
-  char* p = (char*)"abc";       // OK: cast added
   f(p);
-  f((char*)"def");              // OK: cast added
 }
 ```
 Programs that have a legitimate reason to treat string literal objects
 as potentially modifiable memory are probably rare.
@@ -89,16 +97,26 @@ fundamental types and user-defined types. **Effect on original
 feature:** Deletion of semantically well-defined feature. Semantic
 transformation. In C++, the initializer for one of a set of
 mutually-referential file-local objects with static storage duration
 must invoke a function call to achieve the initialization. Seldom.
-**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. Semantic
-transformation. 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.
 \[also [[dcl.type]]\] **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
@@ -136,14 +154,14 @@ 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. Could be
 automated. Violations will be diagnosed by the C++ translator. The fix
 is to add a cast. For example:
 ``` cpp
 char* c = (char*) b;
@@ -151,26 +169,20 @@ char* c = (char*) b;
 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.
-**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. Syntactic
-transformation. Facilities for producing explicit function declarations
-are fairly widespread commercially. Common.
 **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 ) is ill-formed in
-this International Standard.
-**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,
 ``` cpp
 p = (void*)(struct x {int i;} *)0;
 ```
@@ -200,13 +212,13 @@ casts to the appropriate rvalue. Rare.
 **Change:** It is now invalid to jump past a declaration with explicit
 or implicit initializer (except across entire block not entered).
 **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. Semantic transformation. Seldom.
 **Change:** It is now invalid to return (explicitly or implicitly) from
 a function which is declared to return a value without actually
@@ -214,16 +226,16 @@ 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. Semantic transformation. Add an
-appropriate return value to the source code, such as zero. Seldom. For
-several years, many existing C implementations have produced warnings in
-this case.
 ###  [[dcl.dcl]]: declarations <a id="diff.dcl">[[diff.dcl]]</a>
 **Change:** In C++, the `static` or `extern` specifiers can only be
 applied to names of objects or functions.
@@ -238,23 +250,23 @@ static struct S {               // valid C, invalid in C++{}
 };
 ```
 **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.
-Syntactic transformation. Seldom.
 **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. Syntactic transformation. Common.
-**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:
@@ -283,35 +295,15 @@ Seldom.
 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. Semantic transformation. Seldom.
-**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++:
-``` cpp
-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. Syntactic
-transformation. Could be automated. Common.
 **Change:** The keyword `auto` cannot be used as a storage class
 specifier.
 ``` cpp
 void f() {
   auto int x;       // valid C, invalid C++{}
 }
 ```
@@ -446,10 +438,25 @@ sizeof(A) == sizeof(e)          // in C++{}
 original feature:** Change to semantics of well-defined feature.
 Semantic transformation. 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.
 ###  [[class]]: classes <a id="diff.class">[[diff.class]]</a>
 \[see also [[dcl.typedef]]\] **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
@@ -508,15 +515,15 @@ semantically well-defined feature. 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. Seldom.
 **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 types, too.
-**Effect on original feature:** The choice is implementation-defined in
-C, but not so in C++. Syntactic transformation. Seldom.
 **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.
@@ -536,27 +543,27 @@ 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. 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:
 ``` cpp
 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
 [[basic.scope]]. Seldom.
-**Change:** In C++, a typedef name may not be redeclared in a class
 definition after being used in that definition.
 Example:
 ``` cpp
@@ -577,11 +584,9 @@ renamed. Seldom.
 ###  [[cpp]]: preprocessing directives <a id="diff.cpp">[[diff.cpp]]</a>
 **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. Semantic
-transformation. Programs and headers that reference `__STDC__` are quite
-common.

 ## C++ and ISO C <a id="diff.iso">[[diff.iso]]</a>
+### General <a id="diff.iso.general">[[diff.iso.general]]</a>
+Subclause [[diff.iso]] lists the differences between C++ and ISO C, in
+addition to those listed above, by the chapters of this document.
 ###  [[lex]]: lexical conventions <a id="diff.lex">[[diff.lex]]</a>
 **Change:** New Keywords
 New keywords are added to C++; see [[lex.key]]. **Rationale:** These
 ```
 will not work the same as C++ programs. Simple. Programs which depend
 upon `sizeof('x')` are probably rare.
+**Change:** Concatenated *string-literal*s can no longer have
+conflicting *encoding-prefix*es. **Rationale:** Removal of non-portable
+feature. **Effect on original feature:** Concatenation of
+*string-literal*s with different *encoding-prefix*es is now ill-formed.
+Syntactic transformation. Seldom.
 **Change:** String literals made const.
 The type of a *string-literal* is changed from “array of `char`” to
 “array of `const char`”. The type of a UTF-8 string literal is changed
 from “array of `char`” to “array of `const char8_t`”. The type of a
 UTF-16 string literal is changed from “array of *some-integer-type*” to
 The fix is to add a cast:
 ``` cpp
 char* p = "abc";                // valid in C, invalid in C++{}
 void f(char*) {
+  char* p = (char*)"abc";       // OK, cast added
   f(p);
+  f((char*)"def");              // OK, cast added
 }
 ```
 Programs that have a legitimate reason to treat string literal objects
 as potentially modifiable memory are probably rare.
 feature:** Deletion of semantically well-defined feature. Semantic
 transformation. In C++, the initializer for one of a set of
 mutually-referential file-local objects with static storage duration
 must invoke a function call to achieve the initialization. Seldom.
+**Change:** A `struct` is a scope in C++, not in C. For example,
+``` cpp
+struct X {
+  struct Y { int a; } b;
+};
+struct Y c;
+```
+is valid in C but not in C++, which would require `X::Y 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. Semantic transformation. 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.
 \[also [[dcl.type]]\] **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
 void foo() {
   char* c=b;
 }
 ```
+ISO C accepts this usage of pointer to `void` being assigned to a
+pointer to object type. C++ does not. **Rationale:** C++ tries harder
 than C to enforce compile-time type safety. **Effect on original
+feature:** Deletion of semantically well-defined feature. Can be
 automated. Violations will be diagnosed by the C++ translator. The fix
 is to add a cast. For example:
 ``` cpp
 char* c = (char*) b;
 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.
 **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 C++.
+**Change:** In C++, types can only be defined in declarations, not in
+expressions.
+In C, a `sizeof` expression or cast expression may define a new type.
+For example,
 ``` cpp
 p = (void*)(struct x {int i;} *)0;
 ```
 **Change:** It is now invalid to jump past a declaration with explicit
 or implicit initializer (except across entire block not entered).
 **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, many operations on such an uninitialized object
+have undefined behavior. 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. Semantic transformation. Seldom.
 **Change:** It is now invalid to return (explicitly or implicitly) from
 a function which is declared to return a value without actually
 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 functions
+with `void` and `int` return types. **Effect on original feature:**
+Deletion of semantically well-defined feature. Semantic transformation.
+Add an appropriate return value to the source code, such as zero.
+Seldom. For several years, many existing C implementations have produced
+warnings in this case.
 ###  [[dcl.dcl]]: declarations <a id="diff.dcl">[[diff.dcl]]</a>
 **Change:** In C++, the `static` or `extern` specifiers can only be
 applied to names of objects or functions.
 };
 ```
 **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. Storage class specifiers on type
+declarations can be confusing for users. **Effect on original feature:**
+Deletion of semantically well-defined feature. Syntactic transformation.
+Seldom.
 **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. Syntactic transformation. Common.
+**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:
 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. Semantic transformation. Seldom.
 **Change:** The keyword `auto` cannot be used as a storage class
 specifier.
+Example:
 ``` cpp
 void f() {
   auto int x;       // valid C, invalid C++{}
 }
 ```
 original feature:** Change to semantics of well-defined feature.
 Semantic transformation. 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.
+**Change:** In C++, an *alignment-specifier* is an
+*attribute-specifier*. In C, an *alignment-specifier* is a .
+Example:
+``` cpp
+#include <stdalign.h>
+unsigned alignas(8) int x;      // valid C, invalid C++{}
+unsigned int y alignas(8);      // valid C++{}, invalid C
+```
+**Rationale:** C++ requires unambiguous placement of the
+*alignment-specifier*. **Effect on original feature:** Deletion of
+semantically well-defined feature. Syntactic transformation. Seldom.
 ###  [[class]]: classes <a id="diff.class">[[diff.class]]</a>
 \[see also [[dcl.typedef]]\] **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
 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. Seldom.
 **Change:** Bit-fields of type plain `int` are signed. **Rationale:**
+The signedness needs to be consistent among template specializations.
+For consistency, the implementation freedom was eliminated for
+non-dependent types, too. **Effect on original feature:** The choice is
+implementation-defined in C, but not so in C++. Syntactic
+transformation. Seldom.
 **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.
 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. Semantic transformation. To
 make the struct type name visible in the scope of the enclosing struct,
+the struct tag can be declared in the scope of the enclosing struct,
 before the enclosing struct is defined. Example:
 ``` cpp
 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 can
 be exported to the scope of the enclosing struct. Note: this is a
 consequence of the difference in scope rules, which is documented in
 [[basic.scope]]. Seldom.
+**Change:** In C++, a *typedef-name* may not be redeclared in a class
 definition after being used in that definition.
 Example:
 ``` cpp
 ###  [[cpp]]: preprocessing directives <a id="diff.cpp">[[diff.cpp]]</a>
 **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. **Effect on original feature:** Change to
+semantics of well-defined feature. Semantic transformation. Programs and
+headers that reference `__STDC__` are quite common.

Diff to HTML by rtfpessoa