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

Files changed (1) hide show

tmp/tmp2zgj9ype/{from.md → to.md} +200 -70

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

@@ -1,37 +1,43 @@
-## 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
 keywords were added in order to implement the new semantics of C++.
 **Effect on original feature:** Change to semantics of well-defined
-feature. Any ISO C programs that used any of these keywords as
-identifiers are not valid C++ programs. Syntactic transformation.
-Converting one specific program is easy. Converting a large collection
-of related programs takes more work. Common.
 **Change:** Type of *character-literal* is changed from `int` to `char`.
 **Rationale:** This is needed for improved overloaded function argument
-type matching. For example:
 ``` cpp
 int function( int i );
 int function( char c );
 function( 'x' );
 ```
 It is preferable that this call match the second version of function
-rather than the first. **Effect on original feature:** Change to
-semantics of well-defined feature. ISO C programs which depend on
 ``` cpp
 sizeof('x') == sizeof(int)
 ```
@@ -71,46 +77,62 @@ Programs that have a legitimate reason to treat string literal objects
 as potentially modifiable memory are probably rare.
 ###  [[basic]]: basics <a id="diff.basic">[[diff.basic]]</a>
 **Change:** C++ does not have “tentative definitions” as in C.
-E.g., at file scope,
 ``` cpp
 int i;
 int i;
 ```
-is valid in C, invalid in C++. This makes it impossible to define
-mutually referential file-local objects with static storage duration, if
-initializers are restricted to the syntactic forms of C. For example,
 ``` cpp
 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. 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`.
@@ -143,73 +165,145 @@ 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. Common.
 ###  [[expr]]: expressions <a id="diff.expr">[[diff.expr]]</a>
-**Change:** Converting `void*` to a pointer-to-object type requires
-casting.
 ``` cpp
 char a[10];
 void* b=a;
 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;
 ```
-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.
-Syntactic transformation. Seldom.
 **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, function calls may yield 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,
 ``` cpp
 char arr[100];
 sizeof(0, arr)
 ```
-yields `100` in C++ and `sizeof(char*)` in C. Programs must add explicit
-casts to the appropriate rvalue. Rare.
-###  [[stmt.stmt]]: statements <a id="diff.stat">[[diff.stat]]</a>
 **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
@@ -233,25 +327,27 @@ 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.
 Using these specifiers with type declarations is illegal in C++. In C,
 these specifiers are ignored when used on type declarations.
-Example:
 ``` cpp
 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. Storage class specifiers on type
 declarations can be confusing for users. **Effect on original feature:**
 Deletion of semantically well-defined feature. Syntactic transformation.
@@ -266,29 +362,33 @@ feature. Syntactic transformation. Common.
 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:
 ``` cpp
 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:
 ``` cpp
 class name { ... };
 name i;                         // i has type class name
 ```
 **Effect on original feature:** Deletion of semantically well-defined
 feature. Semantic transformation. One of the 2 types has to be renamed.
 Seldom.
 \[see also [[basic.link]]\] **Change:** Const objects must be
@@ -298,55 +398,60 @@ 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++{}
 }
 ```
 **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.
 Syntactic transformation. Rare.
 **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:
 ``` cpp
 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. Syntactic transformation. The function
-declarations using C incomplete declaration 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. Common.
 \[see [[expr.sizeof]]\] **Change:** In C++, types may not be defined in
 return or parameter types. In C, these type definitions are allowed.
-Example:
 ``` cpp
 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:**
@@ -366,24 +471,26 @@ 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:
 ``` cpp
 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++. Syntactic transformation. Out-of-order
 initializers are common. The other features are seldom used.
@@ -391,16 +498,18 @@ initializers are common. The other features are seldom used.
 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:
 ``` cpp
 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. Semantic transformation. The arrays must be declared one
 element bigger to contain the string terminating `'\0'`. Seldom. This
@@ -408,51 +517,57 @@ style of array initialization is seen as poor coding style.
 **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:
 ``` cpp
 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. Syntactic
 transformation. (The type error produced by the assignment can be
 automatically corrected by applying an explicit cast.) Common.
 **Change:** In C++, the type of an enumerator is its enumeration. In C,
 the type of an enumerator is `int`.
-Example:
 ``` cpp
 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.
 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>
@@ -461,21 +576,23 @@ semantically well-defined feature. Syntactic transformation. Seldom.
 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:
 ``` cpp
 int x[99];
 void f() {
   struct x { int a; };
   sizeof(x);  /* size of the array in C */
   /* size of the struct in \textit{\textrm{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
@@ -491,21 +608,26 @@ is at block scope, either the type or the struct tag has to be renamed.
 Seldom.
 **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:
 ``` cpp
 struct X { int i; };
 volatile struct X x1 = {0};
 struct X x2 = x1;               // invalid C++{}
 struct X x3;
 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
@@ -525,68 +647,76 @@ 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.
-Example:
 ``` cpp
 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. 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
 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.
 Semantic transformation. Either the type or the struct member has to be
 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. **Effect on original feature:** Change to
-semantics of well-defined feature. Semantic transformation. Programs and
-headers that reference `__STDC__` are quite common.

+## C++ and 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 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
 keywords were added in order to implement the new semantics of C++.
 **Effect on original feature:** Change to semantics of well-defined
+feature. Any C programs that used any of these keywords as identifiers
+are not valid C++ programs. Syntactic transformation. Converting one
+specific program is easy. Converting a large collection of related
+programs takes more work. Common.
 **Change:** Type of *character-literal* is changed from `int` to `char`.
 **Rationale:** This is needed for improved overloaded function argument
+type matching.
+[*Example 1*:
 ``` cpp
 int function( int i );
 int function( char c );
 function( 'x' );
 ```
 It is preferable that this call match the second version of function
+rather than the first.
+— *end example*]
+**Effect on original feature:** Change to semantics of well-defined
+feature. C programs which depend on
 ``` cpp
 sizeof('x') == sizeof(int)
 ```
 as potentially modifiable memory are probably rare.
 ###  [[basic]]: basics <a id="diff.basic">[[diff.basic]]</a>
 **Change:** C++ does not have “tentative definitions” as in C.
+[*Example 1*:
+At file scope,
 ``` cpp
 int i;
 int i;
 ```
+is valid in C, invalid in C++.
+— *end example*]
+This makes it impossible to define mutually referential file-local
+objects with static storage duration, if initializers are restricted to
+the syntactic forms of C.
+[*Example 2*:
 ``` cpp
 struct X { int i; struct X* next; };
 static struct X a;
 static struct X b = { 0, &a };
 static struct X a = { 1, &b };
 ```
+— *end example*]
 **Rationale:** This avoids having different initialization rules for
 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.
+[*Example 3*:
 ``` 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;`.
+— *end example*]
 **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`.
 typesafe linkage will continue to function properly, according to the
 “layout compatibility rules” of this document. Common.
 ###  [[expr]]: expressions <a id="diff.expr">[[diff.expr]]</a>
+**Change:** Converting a prvalue of type “pointer to cv `void`” to a
+pointer-to-object type requires casting.
+[*Example 1*:
 ``` cpp
 char a[10];
 void* b=a;
 void foo() {
   char* c=b;
 }
 ```
+C accepts this usage of “pointer to `void`” being assigned to a pointer
+to object type. C++ does not.
+— *end example*]
+**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.
+[*Example 2*:
 ``` cpp
 char* c = (char*) b;
 ```
+— *end example*]
+Common.
+**Change:** Operations mixing a value of an enumeration type and a value
+of a different enumeration type or of a floating-point type are not
+valid.
+[*Example 3*:
+``` cpp
+enum E1 { e };
+enum E2 { f };
+int b = e <= 3.7;       // valid in C; ill-formed in C++{}
+int k = f - e;          // valid in C; ill-formed in C++{}
+int x = 1 ? e : f;      // valid in C; ill-formed in C++{}
+```
+— *end example*]
+**Rationale:** Reinforcing type safety in C++. **Effect on original
+feature:** Well-formed C code will not compile with this International
+Standard. Violations will be diagnosed by the C++ translator. The
+original behavior can be restored with a cast or integral promotion.
+[*Example 4*:
+``` cpp
+enum E1 { e };
+enum E2 { f };
+int b = (int)e <= 3.7;
+int k = +f - e;
+```
+— *end example*]
+Uncommon.
 **Change:** Decrement operator is not allowed with `bool` operand.
 **Rationale:** Feature with surprising semantics. **Effect on original
+feature:** A valid 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.
+[*Example 5*:
 ``` cpp
 p = (void*)(struct x {int i;} *)0;
 ```
+defines a new type, struct `x`.
+— *end example*]
+**Rationale:** This prohibition helps to clarify the location of
+definitions in the source code. **Effect on original feature:** Deletion
+of semantically well-defined feature. Syntactic transformation. Seldom.
+**Change:** C allows directly comparing two objects of array type; C++
+does not. **Rationale:** The behavior is confusing because it compares
+not the contents of the two arrays, but their addresses. **Effect on
+original feature:** Deletion of semantically well-defined feature that
+had unspecified behavior in common use cases. Violations will be
+diagnosed by the C++ translator. The original behavior can be replicated
+by explicitly casting either array to a pointer, such as by using a
+unary `+`.
+[*Example 6*:
+``` cpp
+int arr1[5];
+int arr2[5];
+int same = arr1 == arr2;        // valid C, ill-formed C++
+int idem = arr1 == +arr2;       // valid in both C and C++
+```
+— *end example*]
+Rare.
 **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, function calls may yield 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.
+[*Example 7*:
 ``` cpp
 char arr[100];
 sizeof(0, arr)
 ```
+yields `100` in C++ and `sizeof(char*)` in C.
+— *end example*]
+Programs must add explicit casts to the appropriate rvalue. Rare.
+###  [[stmt]]: statements <a id="diff.stat">[[diff.stat]]</a>
 **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
 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]]: 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.
 Using these specifiers with type declarations is illegal in C++. In C,
 these specifiers are ignored when used on type declarations.
+[*Example 1*:
 ``` cpp
 static struct S {               // valid C, invalid in C++{}
   int i;
 };
 ```
+— *end example*]
 **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.
 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 2*:
 ``` cpp
 typedef struct name1 { ... } name1;         // valid C and C++{}
 struct name { ... };
 typedef int name;               // valid C, invalid C++{}
 ```
+— *end example*]
 **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 3*:
 ``` cpp
 class name { ... };
 name i;                         // i has type class name
 ```
+— *end example*]
 **Effect on original feature:** Deletion of semantically well-defined
 feature. Semantic transformation. One of the 2 types has to be renamed.
 Seldom.
 \[see also [[basic.link]]\] **Change:** Const objects must be
 well-defined feature. Semantic transformation. Seldom.
 **Change:** The keyword `auto` cannot be used as a storage class
 specifier.
+[*Example 4*:
 ``` cpp
 void f() {
   auto int x;       // valid C, invalid C++{}
 }
 ```
+— *end example*]
 **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.
 Syntactic transformation. Rare.
 **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 5*:
 ``` cpp
 int f();            // means   int f(void) in C++{}
                     // int f( unknown ) in C
 ```
+— *end example*]
+**Rationale:** This is to avoid 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.
+Syntactic transformation. The function declarations using C incomplete
+declaration 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. Common.
 \[see [[expr.sizeof]]\] **Change:** In C++, types may not be defined in
 return or parameter types. In C, these type definitions are allowed.
+[*Example 6*:
 ``` cpp
 void f( struct S { int a; } arg ) {}    // valid C, invalid C++{}
 enum E { A, B, C } f() {}               // valid C, invalid C++{}
 ```
+— *end example*]
 **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:**
 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 7*:
 ``` cpp
 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++{}
 ```
+— *end example*]
 **Rationale:** In C++, members are destroyed in reverse construction
 order and the elements of an initializer list are evaluated in lexical
+order, so member 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++. Syntactic transformation. Out-of-order
 initializers are common. The other features are seldom used.
 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 8*:
 ``` cpp
 char array[4] = "abcd";         // valid C, invalid C++{}
 ```
+— *end example*]
 **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. Semantic transformation. The arrays must be declared one
 element bigger to contain the string terminating `'\0'`. Seldom. This
 **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 9*:
 ``` cpp
 enum color { red, blue, green };
 enum color c = 1;               // valid C, invalid C++{}
 ```
+— *end example*]
 **Rationale:** The type-safe nature of C++. **Effect on original
 feature:** Deletion of semantically well-defined feature. Syntactic
 transformation. (The type error produced by the assignment can be
 automatically corrected by applying an explicit cast.) Common.
 **Change:** In C++, the type of an enumerator is its enumeration. In C,
 the type of an enumerator is `int`.
+[*Example 10*:
 ``` cpp
 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) */
 ```
+— *end example*]
 **Rationale:** In C++, an enumeration is a distinct type. **Effect on
 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 11*:
 ``` cpp
 #include <stdalign.h>
 unsigned alignas(8) int x;      // valid C, invalid C++{}
 unsigned int y alignas(8);      // valid C++{}, invalid C
 ```
+— *end example*]
 **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>
 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 1*:
 ``` cpp
 int x[99];
 void f() {
   struct x { int a; };
   sizeof(x);  /* size of the array in C */
   /* size of the struct in \textit{\textrm{C++{}}} */
 }
 ```
+— *end example*]
 **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
 Seldom.
 **Change:** Copying volatile objects.
 The implicitly-declared copy constructor and implicitly-declared copy
+assignment operator cannot make a copy of a volatile lvalue.
+[*Example 2*:
+The following is valid in C:
 ``` cpp
 struct X { int i; };
 volatile struct X x1 = {0};
 struct X x2 = x1;               // invalid C++{}
 struct X x3;
 x3 = x1;                        // also invalid C++{}
 ```
+— *end example*]
 **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
 **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 3*:
 ``` cpp
 struct X {
   struct Y { ... } y;
 };
 struct Y yy;                    // valid C, invalid C++{}
 ```
+— *end example*]
 **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. 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 4*:
 ``` cpp
 struct Y;                       // struct Y and struct X are at the same scope
 struct X {
   struct Y { ... } y;
 };
 ```
+— *end example*]
 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 5*:
 ``` cpp
 typedef int I;
 struct S {
   I i;
   int I;            // valid C, invalid C++{}
 };
 ```
+— *end example*]
 **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.
 Semantic transformation. Either the type or the struct member has to be
 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 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