______________________________________________________________________
Annex C (informative)
Compatibility [diff]
______________________________________________________________________
1 This Annex summarizes the evolution of C++ since the first edition of
The C++ Programming Language and explains in detail the differences
between C++ and C. Because the C language as described by this Inter
national Standard differs from the dialects of Classic C used up till
now, we discuss the differences between C++ and ISO C as well as the
differences between C++ and Classic C.
2 C++ is based on C (K&R78) and adopts most of the changes specified by
the ISO C standard. Converting programs among C++, K&R C, and ISO C
may be subject to vicissitudes of expression evaluation. All differ
ences between C++ and ISO C can be diagnosed by a processor. With the
exceptions listed in this Annex, programs that are both C++ and ISO C
have the same meaning in both languages.
C.1 Extensions [diff.c]
1 This subclause summarizes the major extensions to C provided by C++.
C.1.1 C++ features available in 1985 [diff.early]
1 This subclause summarizes the extensions to C provided by C++ in the
1985 version of its manual:
2 The types of function parameters can be specified (_dcl.fct_) and will
be checked (_expr.call_). Type conversions will be performed
(_expr.call_). This is also in ISO C.
3 Single-precision floating point arithmetic may be used for float
expressions; _basic.fundamental_ and _conv.double_. This is also in
ISO C.
4 Function names can be overloaded; _over_.
5 Operators can be overloaded; _over.oper_.
6 Functions can be inline substituted; _dcl.fct.spec_.
7 Data objects can be const; _dcl.type_. This is also in ISO C.
8 Objects of reference type can be declared; _dcl.ref_ and
_dcl.init.ref_.
9 A free store is provided by the new and delete operators; _expr.new_,
_expr.delete_.
10Classes can provide data hiding (_class.access_), guaranteed initial
ization (_class.ctor_), user-defined conversions (_class.conv_), and
dynamic typing through use of virtual functions (_class.virtual_).
11The name of a class or enumeration is a type name; _class_.
12A pointer to any non-const and non-volatile object type can be
assigned to a void*; _conv.ptr_. This is also in ISO C.
13A pointer to function can be assigned to a void*; _conv.ptr_.
14A declaration within a block is a statement; _stmt.dcl_.
15Anonymous unions can be declared; _class.union_.
C.1.2 C++ features added since 1985 [diff.c++]
1 This subclause summarizes the major extensions of C++ since the 1985
version of this manual:
2 A class can have more than one direct base class (multiple inheri
tance); _class.mi_.
3 Class members can be protected; _class.access_ .
4 Pointers to class members can be declared and used; _dcl.mptr_,
_expr.mptr.oper_.
5 Operators new and delete can be overloaded and declared for a class;
_expr.new_, _expr.delete_, _class.free_. This allows the "assignment
to this" technique for class specific storage management to be removed
to the anachronism subclause; _diff.this_.
6 Objects can be explicitly destroyed; _class.dtor_.
7 Assignment and initialization are defined as memberwise assignment and
initialization; _class.copy_.
8 The overload keyword was made redundant and moved to the anachronism
subclause; _diff.anac_.
9 General expressions are allowed as initializers for static objects;
_dcl.init_.
10Data objects can be volatile; _dcl.type_. Also in ISO C.
11Initializers are allowed for static class members; _class.static_.
12Member functions can be static; _class.static_.
13Member functions can be const and volatile; _class.this_.
14Linkage to non-C++ program fragments can be explicitly declared;
_dcl.link_.
15Operators ->, ->*, and , can be overloaded; _over.oper_.
16Classes can be abstract; _class.abstract_.
17Prefix and postfix application of ++ and -- on a user-defined type can
be distinguished.
18Templates; _temp_.
19Exception handling; _except_.
20The bool type (_basic.fundamental_).
C.2 C++ and ISO C [diff.iso]
1 The subclauses of this subclause list the differences between C++ and
ISO C, by the chapters of this document.
C.2.1 Clause _lex_: lexical conventions [diff.lex]
Subclause _lex.trigraph_
1 Change: C++ style comments (//) are added
A pair of slashes now introduce a one-line comment.
Rationale: This style of comments is a useful addition to the lan
guage.
Effect on original feature: Change to semantics of well-defined fea
ture. A valid ISO C expression containing a division operator fol
lowed immediately by a C-style comment will now be treated as a C++
style comment. For example:
{
int a = 4;
int b = 8 //* divide by a*/ a;
+a;
}
Difficulty of converting: Syntactic transformation. Just add white
space after the division operator.
How widely used: The token sequence //* probably occurs very seldom.
Subclause _lex.key_
2 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 iden
tifiers are not valid C++ programs.
Difficulty of converting: Syntactic transformation. Converting one
specific program is easy. Converting a large collection of related
programs takes more work.
How widely used: Common.
Subclause _lex.ccon_
3 Change: Type of character literal is changed from int to char
Rationale: This is needed for improved overloaded function argument
type matching. For example:
int function( int i );
int function( char c );
function( 'x' );
It is preferable that this call match the second version of function
rather than the first.
Effect on original feature: Change to semantics of well-defined fea
ture. ISO C programs which depend on
sizeof('x') == sizeof(int)
will not work the same as C++ programs.
Difficulty of converting: Simple.
How widely used: Programs which depend upon sizeof('x') are probably
rare.
C.2.2 Clause _basic_: basic concepts [diff.basic]
Subclause _basic.def_
1 Change: C++ does not have "tentative definitions" as in C
E.g., at file scope,
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,
struct X { int i; struct X *next; };
static struct X a;
static struct X b = { 0, &a };
static struct X a = { 1, &b };
Rationale: This avoids having different initialization rules for
built-in types and user-defined types.
Effect on original feature: Deletion of semantically well-defined fea
ture.
Difficulty of converting: Semantic transformation. In C++, the ini
tializer for one of a set of mutually-referential file-local static
objects must invoke a function call to achieve the initialization.
How widely used: Seldom.
Subclause _basic.scope_
2 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 fea
ture.
Difficulty of converting: Semantic transformation.
How widely used: 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.
Subclause _basic.link_ [also _dcl.type_]
3 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 fea
ture.
Difficulty of converting: Semantic transformation
How widely used: Seldom
Subclause _basic.start_
4 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 fea
ture
Difficulty of converting: Trivial: create an intermediary function
such as mymain(argc, argv).
How widely used: Seldom
Subclause _basic.types_
5 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 fea
ture.
Difficulty of converting: Semantic transformation The "typesafe link
age" mechanism will find many, but not all, of such problems. Those
problems not found by typesafe linkage will continue to function prop
erly, according to the "layout compatibility rules" of this
International Standard.
How widely used: Common.
Subclause _conv.ptr_
6 Change: Converting void* to a pointer-to-object type requires casting
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 fea
ture.
Difficulty of converting: Could be automated. Violations will be
diagnosed by the C++ translator. The fix is to add a cast. For exam
ple:
char *c = (char *) b;
How widely used: 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.
Subclause _conv.ptr_
7 Change: Only pointers to non-const and non-volatile objects may be
implicitly converted to void*
Rationale: This improves type safety.
Effect on original feature: Deletion of semantically well-defined fea
ture.
Difficulty of converting: Could be automated. A C program containing
such an implicit conversion from (e.g.) pointer-to-const-object to
void* will receive a diagnostic message. The correction is to add an
explicit cast.
How widely used: Seldom.
C.2.3 Clause _expr_: expressions [diff.expr]
Subclause _expr.call_
1 Change: Implicit declaration of functions is not allowed
Rationale: The type-safe nature of C++.
Effect on original feature: Deletion of semantically well-defined fea
ture. Note: the original feature was labeled as "obsolescent" in ISO
C.
Difficulty of converting: Syntactic transformation. Facilities for
producing explicit function declarations are fairly widespread
commercially.
How widely used: Common.
Subclause _expr.sizeof_, _expr.cast_
2 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,
p = (void*)(struct x {int i;} *)0;
declares a new type, struct x .
Rationale: This prohibition helps to clarify the location of declara
tions in the source code.
Effect on original feature: Deletion of a semantically well-defined
feature.
Difficulty of converting: Syntactic transformation.
How widely used: Seldom.
C.2.4 Clause _stmt.stmt_: statements [diff.stat]
Subclause _stmt.switch_, _stmt.goto_ (switch and goto statements)
1 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 ini
tialized.
Effect on original feature: Deletion of semantically well-defined fea
ture.
Difficulty of converting: S>
Transfer interrupted!