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

Files changed (1) hide show

tmp/tmpkagetu3w/{from.md → to.md} +258 -247

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

@@ -1,24 +1,24 @@
 ## C++ and ISO C <a id="diff.iso">[[diff.iso]]</a>
-This subclause lists the differences between C++and ISO C, by the
-chapters of this document.
-### Clause  [[lex]]: lexical conventions <a id="diff.lex">[[diff.lex]]</a>
-[[lex.key]] **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.
-[[lex.ccon]] **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 );
@@ -34,49 +34,49 @@ sizeof('x') == sizeof(int)
 ```
 will not work the same as C++ programs. Simple. Programs which depend
 upon `sizeof('x')` are probably rare.
-Subclause [[lex.string]]: **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 `char16_t` string literal is changed
-from “array of *some-integer-type*” to “array of `const char16_t`”. The
-type of a `char32_t` string literal is changed from “array of
-*some-integer-type*” to “array of `const char32_t`”. The type of a wide
-string literal is changed from “array of `wchar_t`” to “array of
-`const wchar_t`”. **Rationale:** This avoids calling an inappropriate
-overloaded function, which might expect to be able to modify its
-argument. **Effect on original feature:** 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 literals as
-pointers to potentially modifiable memory are probably rare.
-### Clause  [[basic]]: basic concepts <a id="diff.basic">[[diff.basic]]</a>
-[[basic.def]] **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 static objects, if initializers are
-restricted to the syntactic forms of C. For example,
 ``` cpp
 struct X { int i; struct X* next; };
 static struct X a;
@@ -86,94 +86,89 @@ 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 static objects must invoke a function
-call to achieve the initialization. Seldom.
-[[basic.scope]] **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.
-[[basic.link]] \[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 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. Semantic transformation. Seldom.
-[[basic.start.main]] **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. Trivial: create an
-intermediary function such as `mymain(argc, argv)`. Seldom.
-[[basic.types]] **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.
 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 International Standard. Common.
-### Clause  [[conv]]: standard conversions <a id="diff.conv">[[diff.conv]]</a>
-[[conv.ptr]] **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 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;
 ```
 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.
-### Clause  [[expr]]: expressions <a id="diff.expr">[[diff.expr]]</a>
-[[expr.call]] **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.
-[[expr.post.incr]], [[expr.pre.incr]] **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.
-[[expr.sizeof]], [[expr.cast]] **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;
@@ -182,44 +177,43 @@ 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.
-[[expr.cond]], [[expr.ass]], [[expr.comma]] **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,
 ``` 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.
-### Clause  [[stmt.stmt]]: statements <a id="diff.stat">[[diff.stat]]</a>
-[[stmt.switch]], [[stmt.goto]] **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.
-[[stmt.return]] **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
@@ -227,21 +221,21 @@ 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.
-### Clause  [[dcl.dcl]]: declarations <a id="diff.dcl">[[diff.dcl]]</a>
-[[dcl.stc]] **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
@@ -249,27 +243,27 @@ 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.
-[[dcl.stc]] **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.
-[[dcl.typedef]] **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:
 ``` 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.
@@ -283,18 +277,17 @@ 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.
-[[dcl.type]] \[see also [[basic.link]]\] **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. Semantic transformation.
-Seldom.
-[[dcl.type]] **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++:
@@ -312,69 +305,33 @@ 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.
-[[dcl.spec.auto]] **Change:** The keyword `auto` cannot be used as a
-storage class specifier.
 ``` 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.
-[[dcl.enum]] **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.
-[[dcl.enum]] **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.
-### Clause  [[dcl.decl]]: declarators <a id="diff.decl">[[diff.decl]]</a>
-[[dcl.fct]] **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
@@ -384,74 +341,131 @@ 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.
-[[dcl.fct]] \[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:**
 Deletion of semantically well-defined feature. Semantic transformation.
 The type definitions must be moved to file scope, or in header files.
 Seldom. This style of type definition is seen as poor coding style.
-[[dcl.fct.def]] **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. Syntactic transformation. Common in
-old programs, but already known to be obsolescent.
-[[dcl.init.string]] **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:
 ``` 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
 style of array initialization is seen as poor coding style.
-### Clause  [[class]]: classes <a id="diff.class">[[diff.class]]</a>
-[[class.name]] \[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 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 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
@@ -463,33 +477,58 @@ 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.
 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.
 Seldom.
-[[class.bit]] **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.
-[[class.nest]] **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
@@ -513,64 +552,36 @@ 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.
-[[class.nested.type]] **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.
-### Clause  [[special]]: special member functions <a id="diff.special">[[diff.special]]</a>
-[[class.copy]] **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
-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. 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.
-### Clause  [[cpp]]: preprocessing directives <a id="diff.cpp">[[diff.cpp]]</a>
-[[cpp.predefined]] **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>
+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
 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 );
 ```
 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
+“array of `const char16_t`”. The type of a UTF-32 string literal is
+changed from “array of *some-integer-type*” to “array of
+`const char32_t`”. The type of a wide string literal is changed from
+“array of `wchar_t`” to “array of `const wchar_t`”. **Rationale:** This
+avoids calling an inappropriate overloaded function, which might expect
+to be able to modify its argument. **Effect on original feature:**
+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.
+###  [[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;
 **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. **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
+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. Semantic transformation. Seldom.
+**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. Trivial: create an intermediary
+function such as `mymain(argc, argv)`. Seldom.
+**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.
 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. 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 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;
 ```
 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;
 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
+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
+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
 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
 `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:
 ``` 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.
 **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
+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++:
 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++{}
 }
 ```
 **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
 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:**
 Deletion of semantically well-defined feature. Semantic transformation.
 The type definitions must be moved to file scope, or in header files.
 Seldom. This style of type definition is seen as poor coding style.
+**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. Syntactic transformation. Common in old programs,
+but already known to be obsolescent.
+**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:
 ``` 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.
+**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:
+``` 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
 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.
+###  [[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
+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
 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.
 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.
 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
+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. 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.
 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
 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
 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. 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.

Diff to HTML by rtfpessoa