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

Files changed (1) hide show

tmp/tmpt3cbx8f9/{from.md → to.md} +104 -91

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

@@ -13,12 +13,12 @@ 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,18 +34,18 @@ 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:
@@ -62,11 +62,12 @@ 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;
 ```
@@ -84,53 +85,53 @@ 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. **Rationale:** 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 can be used as
-compile-time values in C++, this feature urges programmers to provide
-explicit initializer values for each `const`. This feature allows the
-user to put `const`objects in header files that are included in many
-compilation units. **Effect on original feature:** Change to semantics
-of well-defined feature. Semantic transformation Seldom
-[[basic.start]] **Change:** Main 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() {
@@ -154,38 +155,44 @@ 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.sizeof]], [[expr.cast]] **Change:** Types must be declared in
-declarations, not in expressions In C, a sizeof expression or cast
-expression may create a new type. For example,
 ``` cpp
 p = (void*)(struct x {int i;} *)0;
 ```
-declares a new type, struct x . **Rationale:** This prohibition helps to
-clarify the location of declarations in the source code. **Effect on
-original feature:** Deletion of a 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)
 ```
@@ -195,23 +202,23 @@ 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 run-time 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,
@@ -223,13 +230,13 @@ 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++
@@ -242,57 +249,63 @@ 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.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.
 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.
-[[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++:
 ``` 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
@@ -316,11 +329,11 @@ variable from its initializer results in undesired interpretations of
 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 };
@@ -373,50 +386,50 @@ 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 compilation units,
 C++relies on name equivalence when C relies on structural equivalence.
-Regarding parameter types: since the type defined in an 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 definitions 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 routines, 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.
@@ -424,11 +437,12 @@ style of array initialization is seen as poor coding style.
 [[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];
@@ -457,11 +471,11 @@ 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 choise 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
@@ -469,11 +483,11 @@ 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
@@ -481,30 +495,30 @@ 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 of 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.
 [[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;
@@ -514,27 +528,27 @@ struct S {
 };
 ```
 **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
@@ -544,20 +558,19 @@ 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. This user-declared constructor may be
-explicitly defaulted. 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.

 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 );
 ```
 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:
 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;
 ```
 ```
 **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() {
 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;
 ```
+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)
 ```
 ### 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,
 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++
 `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.
 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.
+[[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++:
 ``` 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
 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 };
 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.
 [[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];
 [[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
 Example:
 ``` cpp
 struct X {
+  struct Y { ... } y;
 };
 struct Y yy;                    // valid C, invalid C++
 ```
 **Rationale:** C++classes have member functions which require that
 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 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.
 [[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;
 };
 ```
 **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
 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.

Diff to HTML by rtfpessoa