From Jason Turner

[diff.dcl]

C++23 → Trunk 8.8 KB 73 lines
Current Draft | LaTeX Source
Archived: C++23
Markdown: C++23 | Trunk
Explore in Adventure Game
C++ Weekly: Ep 182

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmpr9w63vza/{from.md → to.md} +43 -22
tmp/tmpr9w63vza/{from.md → to.md} RENAMED
@@ -1,20 +1,22 @@
1
- ### [[dcl.dcl]]: declarations <a id="diff.dcl">[[diff.dcl]]</a>
2
 
3
  **Change:** In C++, the `static` or `extern` specifiers can only be
4
  applied to names of objects or functions.
5
  Using these specifiers with type declarations is illegal in C++. In C,
6
  these specifiers are ignored when used on type declarations.
7
 
8
- Example:
9
 
10
  ``` cpp
11
  static struct S { // valid C, invalid in C++{}
12
  int i;
13
  };
14
  ```
15
 
 
 
16
  **Rationale:** Storage class specifiers don’t have any meaning when
17
  associated with a type. In C++, class members can be declared with the
18
  `static` storage class specifier. Storage class specifiers on type
19
  declarations can be confusing for users. **Effect on original feature:**
20
  Deletion of semantically well-defined feature. Syntactic transformation.
@@ -29,29 +31,33 @@ feature. Syntactic transformation. Common.
29
  name declared in the same scope (except if the typedef is a synonym of
30
  the class name with the same name). In C, a *typedef-name* and a struct
31
  tag name declared in the same scope can have the same name (because they
32
  have different name spaces).
33
 
34
- Example:
35
 
36
  ``` cpp
37
  typedef struct name1 { ... } name1; // valid C and C++{}
38
  struct name { ... };
39
  typedef int name; // valid C, invalid C++{}
40
  ```
41
 
 
 
42
  **Rationale:** For ease of use, C++ doesn’t require that a type name be
43
  prefixed with the keywords `class`, `struct` or `union` when used in
44
  object declarations or type casts.
45
 
46
- Example:
47
 
48
  ``` cpp
49
  class name { ... };
50
  name i; // i has type class name
51
  ```
52
 
 
 
53
  **Effect on original feature:** Deletion of semantically well-defined
54
  feature. Semantic transformation. One of the 2 types has to be renamed.
55
  Seldom.
56
 
57
  \[see also [[basic.link]]\] **Change:** Const objects must be
@@ -61,55 +67,60 @@ useful value. **Effect on original feature:** Deletion of semantically
61
  well-defined feature. Semantic transformation. Seldom.
62
 
63
  **Change:** The keyword `auto` cannot be used as a storage class
64
  specifier.
65
 
66
- Example:
67
 
68
  ``` cpp
69
  void f() {
70
  auto int x; // valid C, invalid C++{}
71
  }
72
  ```
73
 
 
 
74
  **Rationale:** Allowing the use of `auto` to deduce the type of a
75
  variable from its initializer results in undesired interpretations of
76
  `auto` as a storage class specifier in certain contexts. **Effect on
77
  original feature:** Deletion of semantically well-defined feature.
78
  Syntactic transformation. Rare.
79
 
80
  **Change:** In C++, a function declared with an empty parameter list
81
  takes no arguments. In C, an empty parameter list means that the number
82
  and type of the function arguments are unknown.
83
 
84
- Example:
85
 
86
  ``` cpp
87
  int f(); // means int f(void) in C++{}
88
  // int f( unknown ) in C
89
  ```
90
 
91
- **Rationale:** This is to avoid erroneous function calls (i.e., function
92
- calls with the wrong number or type of arguments). **Effect on original
93
- feature:** Change to semantics of well-defined feature. This feature was
94
- marked as “obsolescent” in C. Syntactic transformation. The function
95
- declarations using C incomplete declaration style must be completed to
96
- become full prototype declarations. A program may need to be updated
97
- further if different calls to the same (non-prototype) function have
98
- different numbers of arguments or if the type of corresponding arguments
99
- differed. Common.
 
100
 
101
  \[see [[expr.sizeof]]\] **Change:** In C++, types may not be defined in
102
  return or parameter types. In C, these type definitions are allowed.
103
 
104
- Example:
105
 
106
  ``` cpp
107
  void f( struct S { int a; } arg ) {} // valid C, invalid C++{}
108
  enum E { A, B, C } f() {} // valid C, invalid C++{}
109
  ```
110
 
 
 
111
  **Rationale:** When comparing types in different translation units, C++
112
  relies on name equivalence when C relies on structural equivalence.
113
  Regarding parameter types: since the type defined in a parameter list
114
  would be in the scope of the function, the only legal calls in C++ would
115
  be from within the function itself. **Effect on original feature:**
@@ -129,24 +140,26 @@ compared to the corresponding functionality in C. In C++, designators
129
  for non-static data members must be specified in declaration order,
130
  designators for array elements and nested designators are not supported,
131
  and designated and non-designated initializers cannot be mixed in the
132
  same initializer list.
133
 
134
- Example:
135
 
136
  ``` cpp
137
  struct A { int x, y; };
138
  struct B { struct A a; };
139
  struct A a = {.y = 1, .x = 2}; // valid C, invalid C++{}
140
  int arr[3] = {[1] = 5}; // valid C, invalid C++{}
141
  struct B b = {.a.x = 0}; // valid C, invalid C++{}
142
  struct A c = {.x = 1, 2}; // valid C, invalid C++{}
143
  ```
144
 
 
 
145
  **Rationale:** In C++, members are destroyed in reverse construction
146
  order and the elements of an initializer list are evaluated in lexical
147
- order, so field initializers must be specified in order. Array
148
  designators conflict with *lambda-expression* syntax. Nested designators
149
  are seldom used. **Effect on original feature:** Deletion of feature
150
  that is incompatible with C++. Syntactic transformation. Out-of-order
151
  initializers are common. The other features are seldom used.
152
 
@@ -154,16 +167,18 @@ initializers are common. The other features are seldom used.
154
  string, the number of characters in the string (including the
155
  terminating `'\0'`) must not exceed the number of elements in the array.
156
  In C, an array can be initialized with a string even if the array is not
157
  large enough to contain the string-terminating `'\0'`.
158
 
159
- Example:
160
 
161
  ``` cpp
162
  char array[4] = "abcd"; // valid C, invalid C++{}
163
  ```
164
 
 
 
165
  **Rationale:** When these non-terminated arrays are manipulated by
166
  standard string functions, there is potential for major catastrophe.
167
  **Effect on original feature:** Deletion of semantically well-defined
168
  feature. Semantic transformation. The arrays must be declared one
169
  element bigger to contain the string terminating `'\0'`. Seldom. This
@@ -171,50 +186,56 @@ style of array initialization is seen as poor coding style.
171
 
172
  **Change:** C++ objects of enumeration type can only be assigned values
173
  of the same enumeration type. In C, objects of enumeration type can be
174
  assigned values of any integral type.
175
 
176
- Example:
177
 
178
  ``` cpp
179
  enum color { red, blue, green };
180
  enum color c = 1; // valid C, invalid C++{}
181
  ```
182
 
 
 
183
  **Rationale:** The type-safe nature of C++. **Effect on original
184
  feature:** Deletion of semantically well-defined feature. Syntactic
185
  transformation. (The type error produced by the assignment can be
186
  automatically corrected by applying an explicit cast.) Common.
187
 
188
  **Change:** In C++, the type of an enumerator is its enumeration. In C,
189
  the type of an enumerator is `int`.
190
 
191
- Example:
192
 
193
  ``` cpp
194
  enum e { A };
195
  sizeof(A) == sizeof(int) // in C
196
  sizeof(A) == sizeof(e) // in C++{}
197
  /* and sizeof(int) is not necessarily equal to sizeof(e) */
198
  ```
199
 
 
 
200
  **Rationale:** In C++, an enumeration is a distinct type. **Effect on
201
  original feature:** Change to semantics of well-defined feature.
202
  Semantic transformation. Seldom. The only time this affects existing C
203
  code is when the size of an enumerator is taken. Taking the size of an
204
  enumerator is not a common C coding practice.
205
 
206
  **Change:** In C++, an *alignment-specifier* is an
207
  *attribute-specifier*. In C, an *alignment-specifier* is a .
208
 
209
- Example:
210
 
211
  ``` cpp
212
  #include <stdalign.h>
213
  unsigned alignas(8) int x; // valid C, invalid C++{}
214
  unsigned int y alignas(8); // valid C++{}, invalid C
215
  ```
216
 
 
 
217
  **Rationale:** C++ requires unambiguous placement of the
218
  *alignment-specifier*. **Effect on original feature:** Deletion of
219
  semantically well-defined feature. Syntactic transformation. Seldom.
220
 
 
1
+ ### [[dcl]]: declarations <a id="diff.dcl">[[diff.dcl]]</a>
2
 
3
  **Change:** In C++, the `static` or `extern` specifiers can only be
4
  applied to names of objects or functions.
5
  Using these specifiers with type declarations is illegal in C++. In C,
6
  these specifiers are ignored when used on type declarations.
7
 
8
+ [*Example 1*:
9
 
10
  ``` cpp
11
  static struct S { // valid C, invalid in C++{}
12
  int i;
13
  };
14
  ```
15
 
16
+ — *end example*]
17
+
18
  **Rationale:** Storage class specifiers don’t have any meaning when
19
  associated with a type. In C++, class members can be declared with the
20
  `static` storage class specifier. Storage class specifiers on type
21
  declarations can be confusing for users. **Effect on original feature:**
22
  Deletion of semantically well-defined feature. Syntactic transformation.
 
31
  name declared in the same scope (except if the typedef is a synonym of
32
  the class name with the same name). In C, a *typedef-name* and a struct
33
  tag name declared in the same scope can have the same name (because they
34
  have different name spaces).
35
 
36
+ [*Example 2*:
37
 
38
  ``` cpp
39
  typedef struct name1 { ... } name1; // valid C and C++{}
40
  struct name { ... };
41
  typedef int name; // valid C, invalid C++{}
42
  ```
43
 
44
+ — *end example*]
45
+
46
  **Rationale:** For ease of use, C++ doesn’t require that a type name be
47
  prefixed with the keywords `class`, `struct` or `union` when used in
48
  object declarations or type casts.
49
 
50
+ [*Example 3*:
51
 
52
  ``` cpp
53
  class name { ... };
54
  name i; // i has type class name
55
  ```
56
 
57
+ — *end example*]
58
+
59
  **Effect on original feature:** Deletion of semantically well-defined
60
  feature. Semantic transformation. One of the 2 types has to be renamed.
61
  Seldom.
62
 
63
  \[see also [[basic.link]]\] **Change:** Const objects must be
 
67
  well-defined feature. Semantic transformation. Seldom.
68
 
69
  **Change:** The keyword `auto` cannot be used as a storage class
70
  specifier.
71
 
72
+ [*Example 4*:
73
 
74
  ``` cpp
75
  void f() {
76
  auto int x; // valid C, invalid C++{}
77
  }
78
  ```
79
 
80
+ — *end example*]
81
+
82
  **Rationale:** Allowing the use of `auto` to deduce the type of a
83
  variable from its initializer results in undesired interpretations of
84
  `auto` as a storage class specifier in certain contexts. **Effect on
85
  original feature:** Deletion of semantically well-defined feature.
86
  Syntactic transformation. Rare.
87
 
88
  **Change:** In C++, a function declared with an empty parameter list
89
  takes no arguments. In C, an empty parameter list means that the number
90
  and type of the function arguments are unknown.
91
 
92
+ [*Example 5*:
93
 
94
  ``` cpp
95
  int f(); // means int f(void) in C++{}
96
  // int f( unknown ) in C
97
  ```
98
 
99
+ — *end example*]
100
+
101
+ **Rationale:** This is to avoid function calls with the wrong number or
102
+ type of arguments. **Effect on original feature:** Change to semantics
103
+ of well-defined feature. This feature was marked as “obsolescent” in C.
104
+ Syntactic transformation. The function declarations using C incomplete
105
+ declaration style must be completed to become full prototype
106
+ declarations. A program may need to be updated further if different
107
+ calls to the same (non-prototype) function have different numbers of
108
+ arguments or if the type of corresponding arguments differed. Common.
109
 
110
  \[see [[expr.sizeof]]\] **Change:** In C++, types may not be defined in
111
  return or parameter types. In C, these type definitions are allowed.
112
 
113
+ [*Example 6*:
114
 
115
  ``` cpp
116
  void f( struct S { int a; } arg ) {} // valid C, invalid C++{}
117
  enum E { A, B, C } f() {} // valid C, invalid C++{}
118
  ```
119
 
120
+ — *end example*]
121
+
122
  **Rationale:** When comparing types in different translation units, C++
123
  relies on name equivalence when C relies on structural equivalence.
124
  Regarding parameter types: since the type defined in a parameter list
125
  would be in the scope of the function, the only legal calls in C++ would
126
  be from within the function itself. **Effect on original feature:**
 
140
  for non-static data members must be specified in declaration order,
141
  designators for array elements and nested designators are not supported,
142
  and designated and non-designated initializers cannot be mixed in the
143
  same initializer list.
144
 
145
+ [*Example 7*:
146
 
147
  ``` cpp
148
  struct A { int x, y; };
149
  struct B { struct A a; };
150
  struct A a = {.y = 1, .x = 2}; // valid C, invalid C++{}
151
  int arr[3] = {[1] = 5}; // valid C, invalid C++{}
152
  struct B b = {.a.x = 0}; // valid C, invalid C++{}
153
  struct A c = {.x = 1, 2}; // valid C, invalid C++{}
154
  ```
155
 
156
+ — *end example*]
157
+
158
  **Rationale:** In C++, members are destroyed in reverse construction
159
  order and the elements of an initializer list are evaluated in lexical
160
+ order, so member initializers must be specified in order. Array
161
  designators conflict with *lambda-expression* syntax. Nested designators
162
  are seldom used. **Effect on original feature:** Deletion of feature
163
  that is incompatible with C++. Syntactic transformation. Out-of-order
164
  initializers are common. The other features are seldom used.
165
 
 
167
  string, the number of characters in the string (including the
168
  terminating `'\0'`) must not exceed the number of elements in the array.
169
  In C, an array can be initialized with a string even if the array is not
170
  large enough to contain the string-terminating `'\0'`.
171
 
172
+ [*Example 8*:
173
 
174
  ``` cpp
175
  char array[4] = "abcd"; // valid C, invalid C++{}
176
  ```
177
 
178
+ — *end example*]
179
+
180
  **Rationale:** When these non-terminated arrays are manipulated by
181
  standard string functions, there is potential for major catastrophe.
182
  **Effect on original feature:** Deletion of semantically well-defined
183
  feature. Semantic transformation. The arrays must be declared one
184
  element bigger to contain the string terminating `'\0'`. Seldom. This
 
186
 
187
  **Change:** C++ objects of enumeration type can only be assigned values
188
  of the same enumeration type. In C, objects of enumeration type can be
189
  assigned values of any integral type.
190
 
191
+ [*Example 9*:
192
 
193
  ``` cpp
194
  enum color { red, blue, green };
195
  enum color c = 1; // valid C, invalid C++{}
196
  ```
197
 
198
+ — *end example*]
199
+
200
  **Rationale:** The type-safe nature of C++. **Effect on original
201
  feature:** Deletion of semantically well-defined feature. Syntactic
202
  transformation. (The type error produced by the assignment can be
203
  automatically corrected by applying an explicit cast.) Common.
204
 
205
  **Change:** In C++, the type of an enumerator is its enumeration. In C,
206
  the type of an enumerator is `int`.
207
 
208
+ [*Example 10*:
209
 
210
  ``` cpp
211
  enum e { A };
212
  sizeof(A) == sizeof(int) // in C
213
  sizeof(A) == sizeof(e) // in C++{}
214
  /* and sizeof(int) is not necessarily equal to sizeof(e) */
215
  ```
216
 
217
+ — *end example*]
218
+
219
  **Rationale:** In C++, an enumeration is a distinct type. **Effect on
220
  original feature:** Change to semantics of well-defined feature.
221
  Semantic transformation. Seldom. The only time this affects existing C
222
  code is when the size of an enumerator is taken. Taking the size of an
223
  enumerator is not a common C coding practice.
224
 
225
  **Change:** In C++, an *alignment-specifier* is an
226
  *attribute-specifier*. In C, an *alignment-specifier* is a .
227
 
228
+ [*Example 11*:
229
 
230
  ``` cpp
231
  #include <stdalign.h>
232
  unsigned alignas(8) int x; // valid C, invalid C++{}
233
  unsigned int y alignas(8); // valid C++{}, invalid C
234
  ```
235
 
236
+ — *end example*]
237
+
238
  **Rationale:** C++ requires unambiguous placement of the
239
  *alignment-specifier*. **Effect on original feature:** Deletion of
240
  semantically well-defined feature. Syntactic transformation. Seldom.
241