Repository navigation
Expand file tree
/
Copy pathcompatibility.tex
More file actions
1942 lines (1709 loc) · 55.9 KB
/
Copy pathcompatibility.tex
File metadata and controls
1942 lines (1709 loc) · 55.9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
%!TEX root = std.tex
\infannex{diff}{Compatibility}
\rSec1[diff.iso]{\Cpp and ISO C}
\pnum
\indextext{summary!compatibility~with ISO C}%
This subclause lists the differences between \Cpp and
ISO C, by the chapters of this document.
\rSec2[diff.lex]{Clause~\ref{lex}: lexical conventions}
\ref{lex.key}
\change New Keywords\\
New keywords are added to \Cpp;
see \ref{lex.key}.
\rationale
These keywords were added in order to implement the new
semantics of \Cpp.
\effect
Change to semantics of well-defined feature.
Any ISO C programs that used any of these keywords as identifiers
are not valid \Cpp programs.
\difficulty
Syntactic transformation.
Converting one specific program is easy.
Converting a large collection
of related programs takes more work.
\howwide
Common.
\ref{lex.ccon}
\change Type of character literal is changed from \tcode{int} to \tcode{char}
\rationale
This is needed for improved overloaded function argument type
matching.
For example:
\begin{codeblock}
int function( int i );
int function( char c );
function( 'x' );
\end{codeblock}
It is preferable that this call match the second version of
function rather than the first.
\effect
Change to semantics of well-defined feature.
ISO C programs which depend on
\begin{codeblock}
sizeof('x') == sizeof(int)
\end{codeblock}
will not work the same as \Cpp programs.
\difficulty
Simple.
\howwide
Programs which depend upon \tcode{sizeof('x')} are probably rare.
Subclause \ref{lex.string}:
\change String literals made const\\
The type of a string literal is changed
from ``array of \tcode{char}''
to ``array of \tcode{const char}.''
The type of a \tcode{char16_t} string literal is changed
from ``array of \textit{some-integer-type}''
to ``array of \tcode{const char16_t}.''
The type of a \tcode{char32_t} string literal is changed
from ``array of \textit{some-integer-type}''
to ``array of \tcode{const char32_t}.''
The type of a wide string literal is changed
from ``array of \tcode{wchar_t}''
to ``array of \tcode{const wchar_t}.''
\rationale
This avoids calling an inappropriate overloaded function,
which might expect to be able to modify its argument.
\effect
Change to semantics of well-defined feature.
\difficulty
Syntactic transformation. The fix is to add a cast:
\begin{codeblock}
char* p = "abc"; // valid in C, invalid in \Cpp
void f(char*) {
char* p = (char*)"abc"; // OK: cast added
f(p);
f((char*)"def"); // OK: cast added
}
\end{codeblock}
\howwide
Programs that have a legitimate reason to treat string literals
as pointers to potentially modifiable memory are probably rare.
\rSec2[diff.basic]{Clause \ref{basic}: basic concepts}
\ref{basic.def}
\change \Cpp does not have ``tentative definitions'' as in C
E.g., at file scope,
\begin{codeblock}
int i;
int i;
\end{codeblock}
is valid in C, invalid in \Cpp.
This makes it impossible to define
mutually referential file-local static objects, if initializers are
restricted to the syntactic forms of C.
For example,
\begin{codeblock}
struct X { int i; struct X* next; };
static struct X a;
static struct X b = { 0, &a };
static struct X a = { 1, &b };
\end{codeblock}
\rationale
This avoids having different initialization rules for
fundamental types and user-defined types.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
\rationale
In \Cpp, the initializer for one of a set of
mutually-referential file-local static objects must invoke a function
call to achieve the initialization.
\howwide
Seldom.
\ref{basic.scope}
\change A \tcode{struct} is a scope in \Cpp, not in C
\rationale
Class scope is crucial to \Cpp, and a struct is a class.
\effect
Change to semantics of well-defined feature.
\difficulty
Semantic transformation.
\howwide
C programs use \tcode{struct} extremely frequently, but the
change is only noticeable when \tcode{struct}, enumeration, or enumerator
names are referred to outside the \tcode{struct}.
The latter is probably rare.
\ref{basic.link} [also \ref{dcl.type}]
\change A name of file scope that is explicitly declared \tcode{const}, and not explicitly
declared \tcode{extern}, has internal linkage, while in C it would have external linkage
\rationale
Because \tcode{const} objects can be used as compile-time values in
\Cpp, this feature urges programmers to provide explicit initializer
values for each \tcode{const}.
This feature allows the user to put \tcode{const}objects in header files that are included
in many compilation units.
\effect
Change to semantics of well-defined feature.
\difficulty
Semantic transformation
\howwide
Seldom
\ref{basic.start}
\change Main cannot be called recursively and cannot have its address taken
\rationale
The main function may require special actions.
\effect
Deletion of semantically well-defined feature
\difficulty
Trivial: create an intermediary function such as
\tcode{mymain(argc, argv)}.
\howwide
Seldom
\ref{basic.types}
\change C allows ``compatible types'' in several places, \Cpp does not
For example,
otherwise-identical \tcode{struct} types with different tag names
are ``compatible'' in C but are distinctly different types
in \Cpp.
\rationale
Stricter type checking is essential for \Cpp.
\effect
Deletion of semantically well-defined feature.
\difficulty
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.
\howwide
Common.
\rSec2[diff.conv]{Clause \ref{conv}: standard conversions}
\ref{conv.ptr}
\change Converting \tcode{void*} to a pointer-to-object type requires casting
\begin{codeblock}
char a[10];
void* b=a;
void foo() {
char* c=b;
}
\end{codeblock}
ISO C will accept this usage of pointer to void being assigned
to a pointer to object type.
\Cpp will not.
\rationale
\Cpp tries harder than C to enforce compile-time type safety.
\effect
Deletion of semantically well-defined feature.
\difficulty
Could be automated.
Violations will be diagnosed by the \Cpp translator.
The
fix is to add a cast.
For example:
\begin{codeblock}
char* c = (char*) b;
\end{codeblock}
\howwide
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.
\rSec2[diff.expr]{Clause \ref{expr}: expressions}
\ref{expr.call}
\change Implicit declaration of functions is not allowed
\rationale
The type-safe nature of \Cpp.
\effect
Deletion of semantically well-defined feature.
Note: the original feature was labeled as ``obsolescent'' in ISO C.
\difficulty
Syntactic transformation.
Facilities for producing explicit function declarations are fairly
widespread commercially.
\howwide
Common.
\ref{expr.sizeof}, \ref{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,
\begin{codeblock}
p = (void*)(struct x {int i;} *)0;
\end{codeblock}
declares a new type, struct x .
\rationale
This prohibition helps to clarify the location of
declarations in the source code.
\effect
Deletion of a semantically well-defined feature.
\difficulty
Syntactic transformation.
\howwide
Seldom.
\ref{expr.cond}, \ref{expr.ass}, \ref{expr.comma}
\indextext{conversion!lvalue-to-rvalue}%
\indextext{rvalue!lvalue conversion~to}%
\indextext{lvalue}%
\change The result of a conditional expression, an assignment expression, or a comma expression may be an lvalue
\rationale
\Cpp is an object-oriented language, placing relatively
more emphasis on lvalues. For example, functions may
return lvalues.
\effect
Change to semantics of well-defined feature. Some C
expressions that implicitly rely on lvalue-to-rvalue
conversions will yield different results. For example,
\begin{codeblock}
char arr[100];
sizeof(0, arr)
\end{codeblock}
yields
\tcode{100}
in \Cpp and
\tcode{sizeof(char*)}
in C.
\difficulty
Programs must add explicit casts to the appropriate rvalue.
\howwide
Rare.
\rSec2[diff.stat]{Clause \ref{stmt.stmt}: statements}
\ref{stmt.switch}, \ref{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, \Cpp assures that
if an initialized variable is in scope, then it has assuredly been
initialized.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
\howwide
Seldom.
\ref{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 functions and int functions.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
Add an appropriate return value to the source code, such as zero.
\howwide
Seldom.
For several years, many existing C implementations have produced warnings in
this case.
\rSec2[diff.dcl]{Clause \ref{dcl.dcl}: declarations}
\ref{dcl.stc}
\change In \Cpp, the \tcode{static} or \tcode{extern} specifiers can only be applied to names of objects or functions
Using these specifiers with type declarations is illegal in \Cpp.
In C, these specifiers are ignored when used on type declarations.
Example:
\begin{codeblock}
static struct S { // valid C, invalid in \Cpp
int i;
};
\end{codeblock}
\rationale
Storage class specifiers don't have any meaning when associated
with a type.
In \Cpp, class members can be declared with the \tcode{static} storage
class specifier.
Allowing storage class specifiers on type
declarations could render the code confusing for users.
\effect
Deletion of semantically well-defined feature.
\difficulty
Syntactic transformation.
\howwide
Seldom.
\ref{dcl.typedef}
\change A \Cpp 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:
\begin{codeblock}
typedef struct name1 { /*...*/ } name1; // valid C and \Cpp
struct name { /*...*/ };
typedef int name; // valid C, invalid \Cpp
\end{codeblock}
\rationale
For ease of use, \Cpp doesn't require that a type name be prefixed
with the keywords \tcode{class}, \tcode{struct} or \tcode{union} when used in object
declarations or type casts.
Example:
\begin{codeblock}
class name { /*...*/ };
name i; // \tcode{i} has type \tcode{class name}
\end{codeblock}
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
One of the 2 types has to be renamed.
\howwide
Seldom.
\ref{dcl.type} [see also \ref{basic.link}]
\change const objects must be initialized in \Cpp 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
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
\howwide
Seldom.
\ref{dcl.type}
\change Banning implicit int
In \Cpp a
\grammarterm{decl-specifier-seq}
must contain a
\grammarterm{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 \Cpp :
\begin{codeblock}
void f(const parm); void f(const int parm);
const n = 3; const int n = 3;
main() int main()
/* ... */ /* ... */
\end{codeblock}
\rationale
In \Cpp, implicit int creates several opportunities for
ambiguity between expressions involving function-like
casts and declarations.
Explicit declaration is increasingly considered
to be proper style.
Liaison with WG14 (C) indicated support for (at least)
deprecating implicit int in the next revision of C.
\effect
Deletion of semantically well-defined feature.
\difficulty
Syntactic transformation.
Could be automated.
\howwide
Common.
\ref{dcl.spec.auto}
\change
The keyword \tcode{auto} cannot be used as a storage class specifier.
\begin{codeblock}
void f() {
auto int x; // valid C, invalid C++
}
\end{codeblock}
\rationale Allowing the use of \tcode{auto} to deduce the type
of a variable from its initializer results in undesired interpretations of
\tcode{auto} as a storage class specifier in certain contexts.
\effect Deletion of semantically well-defined feature.
\difficulty Syntactic transformation.
\howwide Rare.
\ref{dcl.enum}
\change \Cpp 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:
\begin{codeblock}
enum color { red, blue, green };
enum color c = 1; // valid C, invalid \Cpp
\end{codeblock}
\rationale
The type-safe nature of \Cpp.
\effect
Deletion of semantically well-defined feature.
\difficulty
Syntactic transformation.
(The type error produced by the assignment can be automatically
corrected by applying an explicit cast.)
\howwide
Common.
\ref{dcl.enum}
\change In \Cpp, the type of an enumerator is its enumeration. In C, the type of an enumerator is \tcode{int}.
Example:
\begin{codeblock}
enum e { A };
sizeof(A) == sizeof(int) // in C
sizeof(A) == sizeof(e) // in \Cpp
/* @\textit{\textrm{and \tcode{sizeof(int)} is not necessarily equal to \tcode{sizeof(e)}}}@ */
\end{codeblock}
\rationale
In \Cpp, an enumeration is a distinct type.
\effect
Change to semantics of well-defined feature.
\difficulty
Semantic transformation.
\howwide
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.
\rSec2[diff.decl]{Clause \ref{dcl.decl}: declarators}
\ref{dcl.fct}
\change In \Cpp, 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:
\begin{codeblock}
int f(); // means \tcode{int f(void)} in \Cpp
// \tcode{int f(} unknown \tcode{)} in C
\end{codeblock}
\rationale
This is to avoid erroneous function calls (i.e., function calls
with the wrong number or type of arguments).
\effect
Change to semantics of well-defined feature.
This feature was marked as ``obsolescent'' in C.
\difficulty
Syntactic transformation.
The function declarations using C incomplete declaration style must
be completed to become full prototype declarations.
A program may need to be updated further if different calls to the
same (non-prototype) function have different numbers of arguments or
if the type of corresponding arguments differed.
\howwide
Common.
\ref{dcl.fct} [see \ref{expr.sizeof}]
\change In \Cpp, types may not be defined in return or parameter types. In C, these type definitions are allowed
Example:
\begin{codeblock}
void f( struct S { int a; } arg ) {} // valid C, invalid \Cpp
enum E { A, B, C } f() {} // valid C, invalid \Cpp
\end{codeblock}
\rationale
When comparing types in different compilation units, \Cpp 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 \Cpp
would be from within the function itself.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
The type definitions must be moved to file scope, or in header files.
\howwide
Seldom.
This style of type definitions is seen as poor coding style.
\ref{dcl.fct.def}
\change In \Cpp, 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
Deletion of semantically well-defined feature.
\difficulty
Syntactic transformation.
\howwide
Common in old programs, but already known to be obsolescent.
\ref{dcl.init.string}
\change In \Cpp, when initializing an array of character with a string, the number of
characters in the string (including the terminating \tcode{'\textbackslash 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 \tcode{'\textbackslash 0'}
Example:
\begin{codeblock}
char array[4] = "abcd"; // valid C, invalid \Cpp
\end{codeblock}
\rationale
When these non-terminated arrays are manipulated by standard
string routines, there is potential for major catastrophe.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
The arrays must be declared one element bigger to contain the
string terminating \tcode{'\textbackslash 0'}.
\howwide
Seldom.
This style of array initialization is seen as poor coding style.
\rSec2[diff.class]{Clause \ref{class}: classes}
\ref{class.name} [see also \ref{dcl.typedef}]
\change In \Cpp, 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:
\begin{codeblock}
int x[99];
void f() {
struct x { int a; };
sizeof(x); /* @\textit{\textrm{size of the array in C}}@ */
/* @\textit{\textrm{size of the struct in \Cpp}}@ */
}
\end{codeblock}
\rationale
This is one of the few incompatibilities between C and \Cpp that
can be attributed to the new \Cpp name space definition where a
name can be declared as a type and as a non-type in a single scope
causing the non-type name to hide the type name and requiring that
the keywords \tcode{class}, \tcode{struct}, \tcode{union} or \tcode{enum} be used to refer to the type name.
This new name space definition provides important notational
conveniences to \Cpp 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
Change to semantics of well-defined feature.
\difficulty
Semantic transformation.
If the hidden name that needs to be accessed is at global scope,
the \tcode{::} \Cpp operator can be used.
If the hidden name is at block scope, either the type or the struct
tag has to be renamed.
\howwide
Seldom.
\ref{class.bit}
\change
\indextext{bit-field!implementation-defined sign~of}%
Bit-fields of type plain \tcode{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
The choise is implementation-defined in C, but not so in C++.
\difficulty
Syntactic transformation.
\howwide
Seldom.
\ref{class.nest}
\change In \Cpp, 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:
\begin{codeblock}
struct X {
struct Y { /* ... */ } y;
};
struct Y yy; // valid C, invalid \Cpp
\end{codeblock}
\rationale
\Cpp classes have member functions which require that classes
establish scopes.
The C rule would leave classes as an incomplete scope mechanism
which would prevent \Cpp programmers from maintaining locality
within a class.
A coherent set of scope rules for \Cpp based on the C rule would
be very complicated and \Cpp programmers would be unable to predict
reliably the meanings of nontrivial examples involving nested or
local functions.
\effect
Change of semantics of well-defined feature.
\difficulty
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:
\begin{codeblock}
struct Y; // \tcode{struct Y} and \tcode{struct X} are at the same scope
struct X {
struct Y { /* ... */ } y;
};
\end{codeblock}
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 \ref{basic.scope}.
\howwide
Seldom.
\ref{class.nested.type}
\change In \Cpp, a typedef name may not be redeclared in a class definition after being used in that definition
Example:
\begin{codeblock}
typedef int I;
struct S {
I i;
int I; // valid C, invalid \Cpp
};
\end{codeblock}
\rationale
When classes become complicated, allowing such a redefinition
after the type has been used can create confusion for \Cpp
programmers as to what the meaning of 'I' really is.
\effect
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
Either the type or the struct member has to be renamed.
\howwide
Seldom.
\rSec2[diff.special]{Clause \ref{special}: special member functions}
\ref{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:
\begin{codeblock}
struct X { int i; };
volatile struct X x1 = {0};
struct X x2(x1); // invalid \Cpp
struct X x3;
x3 = x1; // also invalid \Cpp
\end{codeblock}
\rationale
Several alternatives were debated at length.
Changing the parameter to
\tcode{volatile}
\tcode{const}
\tcode{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
Deletion of semantically well-defined feature.
\difficulty
Semantic transformation.
If volatile semantics are required for the copy,
a user-declared constructor or assignment must
be provided. \enternote This user-declared
constructor may be explicitly defaulted. \exitnote
If non-volatile semantics are required,
an explicit
\tcode{const_cast}
can be used.
\howwide
Seldom.
\rSec2[diff.cpp]{Clause \ref{cpp}: preprocessing directives}
\ref{cpp.predefined}
\change Whether \mname{STDC} is defined and if so, what its value is, are
implementation-defined
\rationale
\Cpp is not identical to ISO C.
Mandating that \mname{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
Change to semantics of well-defined feature.
\difficulty
Semantic transformation.
\howwide
Programs and headers that reference \mname{STDC} are
quite common.
\rSec1[diff.cpp03]{\Cpp and ISO \CppIII}
\pnum
\indextext{summary!compatibility~with ISO \CppIII}%
This subclause lists the differences between \Cpp and
ISO \CppIII (ISO/IEC 14882:2003, \doccite{Programming Languages --- \Cpp}),
by the chapters of this document.
\rSec2[diff.cpp03.lex]{Clause \ref{lex}: lexical conventions}
\ref{lex.pptoken}
\change New kinds of string literals
\rationale Required for new features.
\effect
Valid \CppIII code may fail to compile or produce different results in
this International Standard. Specifically, macros named \tcode{R}, \tcode{u8},
\tcode{u8R}, \tcode{u}, \tcode{uR}, \tcode{U}, \tcode{UR}, or \tcode{LR} will
not be expanded when adjacent to a string literal but will be interpreted as
part of the string literal. For example,
\begin{codeblock}
#define u8 "abc"
const char* s = u8"def"; // Previously \tcode{"abcdef"}, now \tcode{"def"}
\end{codeblock}
\ref{lex.pptoken}
\change User-defined literal string support
\rationale Required for new features.
\effect
Valid \CppIII code may fail to compile or produce different results in
this International Standard, as the following example illustrates.
\begin{codeblock}
#define _x "there"
"hello"_x // \#1
\end{codeblock}
Previously, \#1 would have consisted of two separate preprocessing tokens and
the macro \tcode{_x} would have been expanded. In this International Standard,
\#1 consists of a single preprocessing tokens, so the macro is not expanded.
\ref{lex.key}
\change New keywords
\rationale Required for new features.
\effect
Added to Table~\ref{tab:keywords}, the following identifiers are new keywords:
\tcode{alignas},
\tcode{alignof},
\tcode{char16_t},
\tcode{char32_t},
\tcode{constexpr},
\tcode{decltype},
\tcode{noexcept},
\tcode{nullptr},
\tcode{static_assert},
and
\tcode{thread_local}.
Valid \CppIII code using these identifiers is invalid in this International
Standard.
\ref{lex.icon}
\change Type of integer literals
\rationale C99 compatibility.
\effect
Certain integer literals larger than can be represented by \tcode{long} could
change from an unsigned integer type to \tcode{signed long long}.
\rSec2[diff.cpp03.conv]{Clause~\ref{conv}: standard conversions}
\ref{conv.ptr}
\change Only literals are integer null pointer constants
\rationale Removing surprising interactions with templates and constant
expressions
\effect Valid \CppIII code may fail to compile or produce different results in
this International Standard, as the following example illustrates:
\begin{codeblock}
void f(void *); // \#1
void f(...); // \#2
template<int N> void g() {
f(0*N); // calls \#2; used to call \#1
}
\end{codeblock}
\rSec2[diff.cpp03.expr]{Clause \ref{expr}: expressions}
\ref{expr.mul}
\change Specify rounding for results of integer \tcode{/} and \tcode{\%}
\rationale Increase portability, C99 compatibility.
\effect
Valid \CppIII code that uses integer division rounds the result toward 0 or
toward negative infinity, whereas this International Standard always rounds
the result toward 0.
\rSec2[diff.cpp03.dcl.dcl]{Clause \ref{dcl.dcl}: declarations}
\ref{dcl.spec}
\change Remove \tcode{auto} as a storage class specifier
\rationale New feature.
\effect
Valid \CppIII code that uses the keyword \tcode{auto} as a storage class
specifier may be invalid in this International Standard. In this International
Standard, \tcode{auto} indicates that the type of a variable is to be deduced
from its initializer expression.
\rSec2[diff.cpp03.dcl.decl]{Clause \ref{dcl.decl}: declarators}
\ref{dcl.init.list}
\change Narrowing restrictions in aggregate initializers
\rationale Catches bugs.
\effect
Valid \CppIII code may fail to compile in this International Standard. For
example, the following code is valid in \CppIII but invalid in this
International Standard because \tcode{double} to \tcode{int} is a narrowing
conversion:
\begin{codeblock}
int x[] = { 2.0 };
\end{codeblock}
\rSec2[diff.cpp03.special]{Clause \ref{special}: special member functions}
\ref{class.ctor}, \ref{class.dtor}, \ref{class.copy}
\change Implicitly-declared special member functions are defined as deleted
when the implicit definition would have been ill-formed.
\rationale Improves template argument deduction failure.
\effect
A valid \CppIII program that uses one of these special member functions in a
context where the definition is not required (e.g., in an expression that is
not potentially evaluated) becomes ill-formed.
\ref{class.dtor} (destructors)
\change User-declared destructors have an implicit exception specification.
\rationale Clarification of destructor requirements.
\effect
Valid \CppIII code may execute differently in this International Standard. In
particular, destructors that throw exceptions will call \tcode{std::terminate()}
(without calling \tcode{std::unexpected()}) if their exception specification is
\tcode{noexcept} or \tcode{noexcept(true)}. For a throwing virtual destructor
of a derived class, \tcode{std::terminate()} can be avoided only if the base class
virtual destructor has an exception specification that is not \tcode{noexcept}
and not \tcode{noexcept(true)}.
\rSec2[diff.cpp03.temp]{Clause \ref{temp}: templates}
\ref{temp.param}
\change Remove \tcode{export}
\rationale No implementation consensus.
\effect
A valid \CppIII declaration containing \tcode{export} is ill-formed in this
International Standard.
\ref{temp.arg}
\change Remove whitespace requirement for nested closing template right angle
brackets
\rationale Considered a persistent but minor annoyance. Template aliases
representing nonclass types would exacerbate whitespace issues.
\effect
Change to semantics of well-defined expression. A valid \CppIII expression
containing a right angle bracket (``\tcode{>}'') followed immediately by
another right angle bracket may now be treated as closing two templates.
For example, the following code is valid in \CppIII because ``\tcode{\shr}''
is a right-shift operator, but invalid in this International Standard because
``\tcode{\shr}'' closes two templates.
\begin{codeblock}
template <class T> struct X { };
template <int N> struct Y { };
X< Y< 1 >> 2 > > x;
\end{codeblock}
\ref{temp.dep.candidate}
\change Allow dependent calls of functions with internal linkage
\rationale Overly constrained, simplify overload resolution rules.
\effect
A valid \CppIII program could get a different result than this
International Standard.
\rSec2[diff.cpp03.library]{Clause \ref{library}: library introduction}
\ref{library} -- \ref{\lastlibchapter}
\change New reserved identifiers
\rationale Required by new features.
\effect
Valid \CppIII code that uses any identifiers added to the \Cpp standard
library by this International Standard may fail to compile or produce different
results in This International Standard. A comprehensive list of identifiers used
by the \Cpp standard library can be found in the Index of Library Names in this
International Standard.
\ref{headers}
\change New headers
\rationale New functionality.
\effect
The following \Cpp headers are new:
\tcode{<array>},
\tcode{<atomic>},