The C programming language began to be standardized some time around 1985 by the ANSI X3J9 committee. Several years of effort went by, and in 1989 ANSI approved the new standard. An ISO committee ratified it a year later in 1990 after adding an amendment dealing with internationalization issues. The 1989 C standard is known officially as ANSI/ISO 9899-1989, Programming Languages - C, and this document refers to the 1989 C standard as C89. The 1990 ISO revision of the standard is known officially as ISO/IEC 9899-1990, Programming Languages - C, which is referred to in this document as "C90".

The next version of the C standard was ratified by ISO in 1999. Officially know as ISO/IEC 9899-1999, Programming Languages - C, it is referred to in this document as "C99".

The C++ programming language was based on the C programming language as it existed shortly after the ANSI C standardization effort had begun. Around 1995 an ISO committee was formed to standardize C++, and the new standard was ratified in 1998, which is officially known as ISO/IEC 14882-1998, Programming Languages - C++. It is referred to in this document as "C++98" or simply as "C++".

Though the two languages share a common heritage, and though the designers involved in the standardization processes for each language tried to keep them as compatible as possible, some incompatibilities unavoidably arose. Once the programmer is aware of these potential problem spots, they are easy, for the most part, to avoid when writing C code.

When we say that C is incompatible with C++ with respect to a specific language feature, we mean that a C program that employs that feature either is not valid C++ code and thus will not compile as a C++ program, or that it will compile as a C++ program but will exhibit different behavior than the same program compiled as a C program. In other words, an incompatible C feature is valid as C code but not as C++ code. All incompatibilities of this kind are addressed in this document. Avoiding these kinds of incompatibilities allows the programmer to write correct C code that is intended to interact with, or be compiled as, C++ code.

Another form of incompatible feature is one that is valid when used in a C++ program but is invalid in a C program. We call this an incompatible C++ feature. Huge portions of the C++ language fall into this category (e.g., classes, templates, exceptions, references, member functions, anonymous unions, etc.), so very few of these kinds of incompatibilities are addressed in this document.

Yet another form of incompatible feature occurs when a C++ program uses a feature that has the same name as a C90 feature but which has a different usage or meaning in C. This document covers these kinds of incompatibilities.

This document lists only the incompatibilities between C99 and C++98. (Incompatibilities between C90 and C++ have been documented elsewhere; see Appendix B of Stroustrup [STR], for example.)

New additions to the C99 standard library are also not addressed in this document unless they specifically introduce C++ incompatibilities. C++ versus C

As discussed in the Introduction, no attempt is made in this document to cover incompatible C++ features, i.e., features of the C++ language or library that are not supported in C. Huge portions of C++ and its library fall into this category. A partial list of these features includes:

The following items are incompatibilities between C90 and C++98, but have since been changed in C99 so that they no longer cause problems between the two languages.

Aggregate InitializersC90 requires automatic and register variables of aggregate type (struct, array, or union) to have initializers containing only constant expressions. (Many compilers do not adhere to this restriction, however.)

C99 removes that restriction, allowing non-constant expressions to be used in such initializers.

C++ allows non-constant expressions to be used in initializers for automatic and register variables. (It also allows arbitrary non-constant expressions to be used to initialize static and external variables.)

C90 only recognizes the /*...*/ form of comments. The //... form usually produces a syntax error in C90, but there are rare cases that may compile erroneously without warning:

i = (x//*y*/z++ , w); C99 recognizes both forms of comments.

[C99: §5.1.1.2, 6.4.9] [C++98: §2.1, 2.7]

Conditional expression declarationsC++ allows local variable declarations within conditional expressions (which appear within for, if, while, and switch statements). The scope of the variables declared in this context extends to the end of the statement containing the conditional expression. For example:

for (int i = 0; i < SIZE; i++) a[i] = i + 1; C90 does not allow this feature.

C99 allows this feature, but only within for statements.

[C99: §6.8.5] [C++98: §3.3.2, 6.4, 6.5]

Digraph punctuation tokensC++ recognizes two-character punctuation tokens, called digraphs, which are not recognized by C90. The digraphs and their equivalent tokens are:

Implicit function declarationsC90 allows a function to be implicitly declared at the point of its first use (call), assigning it a return type of int by default. For example:

/* No previous declaration of bar() is in scope */

void foo(void) { bar(); /* Implicit declaration: extern int bar() */ } C++ does not allow implicit function declarations. It is invalid to call a function that does not have a previous declaration in scope.

C99 no longer allows functions to be implicitly declared. The code above is invalid in both C99 and C++.

[C99: §6.5.2.2] [C++98: §5.2.2]

Implicit variable declarationsC90 allows the declaration of a variable, function argument, or structure member to omit the type specifier, implicitly defaulting its type to int.

Intermixed declarations and statementsC90 syntax specifies that all the declarations within a block must appear before the first statement in the block.

C++ does not have this restriction, allowing statements and declarations to appear in any order within a block.

C99 also removes this restriction, allowing intermixed statements and declarations.

void prefind(void) { int i;

for (i = 0; i < SZ; i++) if (find(arr[i])) break;

const char * s; /* Invalid C90, valid C99 and C++ */

s = arr[i]; prepend(s); } [C99: §6.8.2] [C++98: §6, 6.3, 6.7]

C99 versus C++98

The following items comprise the differences between C99 and C++98. Some of these incompatibilities existed between C89 and C++98 and remain unchanged between C99 and C++98, while others are new features that were introduced into C99 that are incompatible with C++98.

Note that features that are specific to C++ and which are not legal C (e.g., class member function declarations) are not included in this section; only language features that are common to both C and C++ are discussed. Most of the features are valid as C but invalid as C++.

Some of these features are likely to be implemented as extensions by many C++ compilers in order to be more compatible with C compilers.

Alternate punctuation token spellingsC++ provides the following keywords as synonyms for punctuation tokens:

C90 does not have these built-in keywords, but it does provide a standard header file that contains definitions for the same words as macros, behaving almost like built-in keywords.

C++ requires implementations to provide an empty header. Including it in a C++ program has no effect on the program. However, C code that does not include the header is free to use these words as identifiers and macro names, which may cause incompatibilities when such code is compiled as C++.

enum oper { nop, and, or, eq, ne };

extern int instr(enum oper op, struct compl *c); The recommended practice for code intended to be compiled as both C and C++ is to use these identifiers only for these special meanings, and only after including .

Array parameter qualifiersC99 provides new declaration syntax for function parameters of array types, allowing type qualifiers (the cv-qualifiers const and volatile, and restrict) to be included within the first set of brackets of an array declarator. The qualifier modifies the type of the array parameter itself. For example, the following declarations are semantically identical:

C99 also allows the static specifier to be placed within the brackets of an array declaration immediately preceding the expression specifying the size of the array. The presence of such a specifer indicates that the array is composed of at least the number of contiguous elements indicated by the size expression. (Presumably this is a hint to the compiler for optimizing access to elements of the array.) For example:

void baz(char s[static 10]) { // s[0] thru s[9] exist and are contiguous ... } None of these new syntactic features are recognized by C++.

(These features might be provided as an extension by some C++ compilers.)

Boolean typeC99 supports the _Bool keyword, which declares a two-valued integer type (capable of representing the values true and false). It also provides a standard header that contains definitions for the following macros:

bool Same as _Boolfalse Equal to (_Bool)0true Equal to (_Bool)1C++ provides bool, false, and true as reserved keywords and implements bool as a true built-in boolean type.

C programs that do not include the header are free to use these keywords as identifiers and macro names, which may cause compatibility problems when such code is compiled as C++. For example:

typedef short bool; // Different

#define false ('\0') // Different #define true (!false) // Different

bool flag = false; The recommended practice is therefore to use these identifiers in C only for these special meanings, and only after including .

(It is likely that an empty header will be provided by most C++ implementations as an extension.)

Character literalsIn C, character literals such as 'a' have type int, and thus sizeof('a') is equal to sizeof(int).

In C++, character literals have type char, and thus sizeof('a') is equal to sizeof(char).

This difference can lead to inconsistent behavior in some code that is compiled as both C and C++.

memset(&i, 'a', sizeof('a')); // Questionable code In practice, this is probably not much of a problem, since character constants are implicitly converted to type int when they appear within expressions in both C and C++.

C++ declares std::clog in as the name of the standard error logging output stream (analogous to the stderr stream). This name is placed into the global namespace if the header is included, and refers to the logarithm function. If defines clog as a preprocessor macro name, it can cause problems with other C++ code.

// C++ code

#include using std::clog;

#include // Possible conflict

void foo(void) { clog << clog(2.718281828) << endl; // Possible conflict } Including both the and the headers in C++ code places both clog names into the std:: namespace, one being a variable and the other being a function, which should not cause any conflicts.

fp = &std::clog; // Unambiguous } It would appear that the safest approach to this potential conflict would be to avoid using both forms of clog within the same source file.

[C99: §7.3.7.2] [C++98: §27.3.1]

Comma operator resultsThe comma operator in C always results in an r-value even if its right operand is an l-value, while in C++ the comma operator will result in an l-value if its right operand is an l-value. This means that certain expressions are valid in C++ but not in C:

Complex floating-point typeC99 provides built-in complex and imaginary floating point types, which are declared using the _Complex and _Imaginary keywords.

There are exactly three complex types and three imaginary types in C99:

_Complex float_Complex double_Complex long double

_Imaginary long double_Imaginary double_Imaginary long doubleC99 also provides a standard header that contains definitions of complex floating point types, macros, and constants. In particular, this header defines the following macros:

complex Same as _Compleximaginary Same as _ImaginaryI i (the complex identity)C code that does not include this header is free to use these words as identifiers and macro names. This was an intentional part of the design of the _Complex and _Imaginary keywords, since this allows existing code that employs the new words to continue working as it did before under C89.

Implicit widening conversions between the complex and imaginary types are provided, which parallel the implicit widening conversions between the non-complex floating point types.

Compound literalsC99 allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expressions; these are called compound literals. For example:

C++ does provides a similar capability through the use of non-default class constructors, but which is not quite as flexible as the C feature:

void predef2() { add(info("e", 0)); // Call constructor info::info() } (This C feature might be provided as an extension by some C++ compilers, but would probably be valid only for POD structure types and arrays of POD types.)

[C99: §6.5.2, 6.5.2.5] [C++98: §5.2.3, 8.5, 12.1, 12.2]

const linkageC specifies that a variable declared with a const qualifier is not a modifiable object. In all other regards, though, it is treated the same as any other variable. Specifically, if a const object with file scope is not explicitly declared static, its name has external linkage and is visible to other source modules.

const int i = 1; // External linkage

extern const int j = 2; // 'extern' optional static const int k = 3; // 'static' required C++ specifies that a const object with file scope has internal linkage by default, meaning that the object's name is not visible outside the source file in which it is declared. A const object must be declared with an explicit extern specifier in order to be visible to other source modules.

Designated initializersC99 introduces the feature of designated initializers, which allows specific members of structures, unions, or arrays to be initialized explicitly by name or subscript. For example:

(This feature might be provided as an extension by some C++ compilers, but would probably be valid only for POD structure types and arrays of POD types. However, C++ already provides a similar capability through the use of non-default class constructors.)

[C99: §6.7.8] [C++98: §8.5.1, 12.1]

Duplicate typedefsC does not allow a given typedef to appear more than once in the same scope.

C++ handles typedefs and type names differently than C, and allows redundant occurrences of a given typedef within the same scope.

Thus the following code is valid in C++ but invalid in C:

typedef int MyInt; typedef int MyInt; // Valid C++, invalid C This means that typedefs that might be included more than once in a program (e.g., common typedefs that occur in multiple header files) should be guarded by preprocessing directives if such source code is meant to be compiled as both C and C++. For example:

Dynamic sizeof evaluationBecause C99 supports variable-length arrays (VLAs), the sizeof operator does not necessarily evaluate to a constant (compile-time) value. Any expression that involves applying the sizeof operator to a VLA operand must be evaluated at runtime (any other use of sizeof can be evaluated at compile time). For example:

size_t dsize(int sz) { float arr[sz]; // VLA, dynamically allocated

if (sz <= 0) return sizeof(sz); // Evaluated at compile time else return sizeof(arr); // Evaluated at runtime } C++ does not support VLAs, so C code that applies the sizeof operator to VLA operands will cause problems when compiled as C++.

[C99: §6.5.3.4, 6.7.5, 6.7.5.2] [C++98: §5.3, 5.3.3]

Empty parameter listsC distinguishes between a function declared with an empty parameter list and a function declared with a parameter list consisting of only void. The former is an unprototyped function taking an unspecified number of arguments, while the latter is a prototyped function taking no arguments.

bar(); // Okay in both C and C++ bar(1); // Error in both C and C++ } C++, on the other hand, makes no distinction between the two declarations and considers them both to mean a function taking no arguments.

// C++ code

extern int xyz();

extern int xyz(void); // Same as 'xyz()' in C++, // Different and invalid in C For code that is intended to be compiled as either C or C++, the best solution to this problem is to always declare functions taking no parameters with an explicit void prototype. For example:

// Compiles as both C and C++ int bosho(void) { ... } Empty function prototypes are a deprecated feature in C99 (as they were in C89).

(This feature is likely to be provided as an extension by many C++ compilers.)

[C99: §6.10.3, 6.10.3.1] [C++98: §16.3., 16.3.1]

Enumeration constantsEnumeration constants in C are essentially just named constants of type signed int. As such, they are constrained to having an initialization value that falls within the range [INT_MIN,INT_MAX]. This also means that for any given enumeration constant RED, the values of sizeof(RED) and sizeof(int) are always the same.

C++ enumeration constants have the same type as their enumeration type, which means that they have the same size and alignment as their underlying integer type. This means that the values of sizeof(RED) and sizeof(int) are not necessarily the same for any given enumeration constant RED. Enumeration constants also have a wider range of possible underlying types in C++ than in C: signed int, unsigned int, signed long, and unsigned long. As such, they also have a wider range of valid initialization values.

This may cause incompatibilities for C code compiled as C++, if the C++ compiler chooses to implement an enumeration type as a different size than it would be in C, or if the program relies on the results of expressions such as sizeof(RED).

Enumeration declarations with trailing commaC99 allows a trailing comma to follow the last enumeration constant initializer within an enumeration type declaration, similar to structure member initialization lists. For example:

enum Color { RED = 0, GREEN, BLUE, }; C++ does not allow this.

(This feature is likely to be provided as an extension by many C++ compilers.)

[C99: §6.7.2.2] [C++98: §7.2]

Enumeration typesC specifies that each enumerated type is a unique type, distinct from all other enumerated types within the same program. The implementation is free to use a different underlying primitive integer type for each enumerated type. This means that sizeof(enum A) and sizeof(enum B) are not necessarily the same. This also means, given that RED is an enumeration constant of type enum Color, that sizeof(RED) and sizeof(enum Color) are not necessarily the same (since all enumeration constants are of type signed int).

All enumeration constants, though, convert to values of type signed int when they appear in expressions. Since enumeration constants cannot portably be wider than int, it might appear that int is the widest enumeration type; however, implementations are free to support wider enumeration integer types. Such extended types may be different than the types used by a C++ compiler, however.

In C, objects of enumeration types may be assigned integer values without the need for a explicit cast. For example:

// C code

enum Color { RED, BLUE, GREEN };

int c = RED; // Cast not needed enum Color col = 1; // Cast not needed C++ also specifies that all enumerated types are unique and distinct types, but it goes further than C to enforce this. In particular, a function name can be overloaded to take an argument of different enumerated types. While objects of enumerated types implicitly convert to integer values, integer values require an explicit cast to be converted into enumerated types. Implicitly converted enumeration values are converted to their underlying integer type, which is not necessarily signed int. For example:

// C++ code

enum Color { ... };

enum Color setColor(int h) { enum Color c;

c = h; // Error, no implicit conversion return c; }

int hue(enum Color c) { return (c + 128); // Implicit conversion, // but might not be signed int } Since a C++ enumeration constant has the same type and size as its enumeration type, this means, given that RED is an enumeration constant of type enum Color, that the values of sizeof(RED) and sizeof(enum Color) are exactly the same, which differs from the rules in C.

There is no guarantee that a given enumeration type is implemented as the same underlying type in both C and C++, or even in different C implementations. This affects the calling interface between C and C++ functions. This may also cause incompatibilities for C code compiled as C++, if the C++ compiler chooses to implement an enumeration type as a different size that it would be in C, or if the program relies on the results of expressions such as sizeof(RED).

Flexible array members (FAMs)This is also known as the struct hack. This specifies a conforming way to declare a structure containing a set of fixed-sized members followed by a flexible array member that can hold an unspecified number of elements. Such a structure is typically allocated by calling malloc(), passing it the number of bytes beyond the fixed portion of the structure to add to the allocation size. For example:

(This feature might be provided as an extension by some C++ compilers, but would probably be valid only for POD structure types.)

[C99: §6.7.2.1] [C++98: §8.3.4]

Function name manglingIn order to implement overloaded functions and member functions, C++ compilers must have a means of mapping the source names of functions into unique symbols in the object code resulting from the compile. For example, the functions ::foo(int), ::foo(float), and Mine::foo() all have identical names (foo) but different calling signatures. In order for the linker to distinguish between the functions during program link time, they must be mangled into different symbolic names.

This differs from the way functions names are mapped into symbolic object names in C, which allows for certain cases of type punning (between signed and unsigned integer types) and non-prototyped extern functions. Therefore C programs compiled as C++ will produce different symbolic names, unless the functions are explicitly declared as having extern "C" linkage. For example:

Another consequence of C++ function name mangling is that identifiers in C++ are not allowed to contain two or more consecutive underscores (e.g., the name foo__bar is invalid). Such names are reserved for the implementation, ostensibly so that it may have a guaranteed means of mangling source function names into unique object symbolic names. (For example, an implementation might choose to mangle the member function Mine::foo(int) into something like foo__4Mine_Fi, which is a symbolic name containing consecutive underscores.)

C does not reserve such names, so a C program is free to use such names in any manner. For example:

Function pointersC++ functions have extern "C++" linkage by default. In order to call C functions from C++, the functions must be declared with extern "C" linkage. This is typically accomplished by placing C function declarations within an extern "C" block:

pf = &mash; // Error, C function address (*pf)(a); } To make the combination of function pointers and extern "C" functions work correctly in C++, function pointers that are assigned addresses of C functions must be changed to have extern "C" linkage.

float pi = 0x3.243F6A88p+03; C99 also provides additional format specifiers for the printf() and scanf() family of standard library functions:

printf("%9.3a", f); printf("%12.6lA", d); (These features are likely to be provided as extensions by many C++ compilers.)

[C99: §6.4.4.2, 6.4.8] [C++98: §2.9, 2.13.3]

IEC 60559 arithmetic supportC99 allows an implementation to pre-define the __STD_IEC_559 preprocessor macro, indicating that it conforms to certain required behavior of the IEC 60559 (a.k.a. IEEE 599) specification regarding floating-point arithmetic and library functions. Implementations that do not pre-define this macro are not require to provide conforming floating-point behavior.

C++ does not make any special provisions for implementations that explicitly support the IEC 60559 floating-point specification.

Conformance to IEC 60559 floating-point arithmetic, and the pre-definition of the __STD_IEC_559 macro, is likely to be provided as an extension by many C++ compilers.

C99 also allows an implementation to pre-define the __STD_IEC_559_COMPLEX preprocessor macro to indicate that it conforms to the behavior specified by IEC 60559 for complex floating-point arithmetic and library functions. This affects the way the _Complex and _Imaginary types are implemented.

C++ provides library functions for complex floating-point arithmetic by providing the complex<> template class, declared in the standard header file. This type is incompatible with the C99 complex types.

Conformance to the complex arithmetic specification, and the pre-definition of the __STD_IEC_559 macro, might also be provided by many C++ compilers, and this would indicate how the complex<> template class is implemented.

[C99: §6.10.8, F, G] [C++98: §16.8]

Inline functionsBoth C99 and C++ allow functions to be defined as inline, which is a hint to the compiler that invocations of such functions can be replaced with inline code expansions rather than actual function calls. Inline functions are not supposed to be a source of incompatibilities between C99 and C++ in practice, but there is a small difference in the semantics of the two languages.

C++ requires all of the definitions for a given inline function to be composed of exactly the same token sequence.

C99, however, allows multiple definitions of a given inline function to be different, and does not require the compiler to detect such differences or issue a diagnostic.

Thus the following two example source files, which define two slightly different versions of the same inline function, constitute acceptable C99 code but invalid C++ code:

int bar(int b) { return twice(b); } This should not be a problem in practice, provided that multiple inline function definitions occur only in shared header files (which ensures that the multiple function definitions are composed of the same token sequences).

(This feature is likely to be provided as an extension by many C++ compilers. Some C++ compilers might also provide a header file as an extension.)

[C99: §7.1.2, 7.18] [C++98: §17.4.1.2, D.5]

Library function prototypesThe C++ standard library header files amend some of the standard C library function declarations so as to be more type-safe when used in C++. For example, the standard C library function declaration:

p = strchr(s, 'a'); // Valid C, invalid C++ This kind of code results in an attempt to assign a const pointer returned from a function to a non-const variable. A simple cast corrects the code, making it valid as both C++ and C code, as in: // Corrected for C++ p = (char *) strchr(s, 'a'); // Valid C and C++ [C99: §7.21.5, 7.24.4.5] [C++98: §17.4.1.2, 21.4]

Library header filesC++ provides the standard C89 library as part of its library.

C99 adds a few header files that are not included as part of the standard C++ library, though:

Even though C++ provides the C89 standard C library headers as part of its library, it deems their use as deprecated. Instead, it encourages programmers to prefer the equivalent set of C++ header files which provide the same functionality as the C header files:

replaced by replaced by replaced by replaced by etc. etc.Deprecating the use of the C header files thus makes the following valid C++98 program possibly invalid under a future revision of standard C++:

#include // Deprecated in C++

int main(void) { printf("Hello, world\n"); return 0; } The program can be modified by removing the use of deprecated features in order to make it portable to future implementations of standard C++:

long long integer typeC99 provides signed long long and unsigned long long integer types to its repertoire of primitive types, which are binary integer types at least 64 bits wide.

C99 also has enhanced lexical rules to allow for integer constants of these types. For example:

long long int i = -9000000000000000000LL; unsigned long long int u = 18000000000000000000LLU; C99 also provides several new macros in , new format specifiers for the printf() and scanf() family of standard library functions, and additional standard library functions that support these types. For example:

Nested structure tagsNested structure types may be declared within other structures. The scope of the inner structure tag extends outside the scope of the outer structure in C, but does not do so in C++. Structure declarations possess their own scope in C++, but do not in C. This applies to any struct, union, and enumerated types declared within a structure declaration. For example:

enum E et; // Nested type is visible in C, // Not visible in C++ In order to be visible in C++, the inner declarations must be explicitly named using its outer class prefix, or they must be declared outside the outer structure so that they have file scope. The former case, for example:

C allows definitions of the same function or object in different source files to be composed of different token sequences, provided that they are semantically identical.

The C++ rules are more strict, requiring the multiple definitions to be composed of identical token sequences. Thus the following code, which contains multiple definitions that are semantically equivalent but syntactically (token-wise) different, is valid in C but invalid in C++:

_Pragma keywordC99 provides the _Pragma keyword, which operates in a similar fashion to the #pragma preprocessor directive. For example, these two constructs are equivalent:

#pragma FLT_ROUND_INF // Preprocessor pragma

_Pragma(FLT_ROUND_INF) // Pragma statementC++ does not support the _Pragma keyword.

(This feature is likely to be provided as an extension by many C++ compilers.)

[C99: §5.1.1.2, 6.10.6, 6.10.9] [C++98: §16.6]

Predefined identifiersC99 provides a predefined identifier, __func__, which acts like a string literal containing the name of the enclosing function. For example:

int incr(int a) { fprintf(dbgf, "%s(%d)\n", __func__, a); return ++a; } (While this feature is likely to be provided as an extension by many C++ compilers, it is unclear what its value would be, especially for member functions within nested template classes declared within nested namespaces.)

[C99: §6.4.2.2, 7.2.1.1, J.2] Reserved keywords in C99C99 has a few reserved keywords that are not recognized by C++:

restrict_Bool_Complex_Imaginary_PragmaThis will cause problems when C code containing these tokens is compiled as C++. For example:

A simple work-around for code that is meant to be compiled as either C or C++ is to use a macro for the restrict keyword:

#ifdef __cplusplus #define restrict /* nothing */ #endif (This feature is likely to be provided as an extension by many C++ compilers. If it is, it is also likely to be allowed as a reference modifier as well as a pointer modifier.)

static linkageBoth C and C++ allow objects and functions to have static file linkage, also known as internal linkage. C++, however, deems this as deprecated practice, preferring the use of unnamed namespaces instead. (C++ objects and functions declared within unnamed namespaces have external linkage unless they are explicitly declared static. C++ deems the use of static specifiers on objects or function declarations within namespace scope as deprecated.)

While it is not a problem for C code compiled under C++98 rules, it may become a problem in a future revision of the C++ language. For example, the following fragment uses the deprecated static feature:

// C and C++ code

static int bufsize = 1024; static int counter = 0;

static long square(long x) { return (x * x); } The preferred way of doing this in C++ is:

String initializersC allows character arrays to be initialized with string constants. It also allows a string constant initializer to contain exactly one more character than the array it initializes, i.e., the implicit terminating null character of the string may be ignored. For example:

char name4[5] = "Harry"; // Array of 5 char, no null char C++ also allows character arrays to be initialized with string constants, but always includes the terminating null character in the initialization. Thus the last initializer (name4) in the example above is invalid in C++.

[C99: §6.7.8] [C++98: §8.5, 8.5.2]

String literals are constIn C, string literals have type char[n], but are not modifiable (i.e., attempting to modify the contents of a string literal is undefined behavior).

In C++, string literals have type const char[n] and are also not modifiable.

When a string literal is used in an expression (or passed to a function), both C and C++ implicit convert it into a pointer of type char *. (The C++ conversion is considered to be two conversions, the first being an array-to-pointer conversion from type const char[n] to type const char *, and the second being a qualification conversion to type char *.)

The following code is valid in both C and C++.

extern void frob(char *s); // Argument is not const char *

void foo(void) { frob("abc"); // Valid in both C and C++, // since literal converts to char * } This language feature does not present an incompatibility between C99 and C++98. However, the implicit conversion has been deprecated in C++ (presumably to be replaced by a single implicit conversion to type const char *), which means that a future revision of C++ may no longer accept the code above as valid code.

extern struct pt { int x; } pos(void); C++ does not allow either of these, since the scope of the structure declared in this fashion does not extend outside the function declaration or definition, making it impossible to define objects of that structure type which could be passed as arguments to the function or to assign function return values into objects of that type.

Both C and C++ allow declarations of incomplete structure types within function prototypes and as function return types, though:

Type-generic math functionsC99 supports type-generic mathematical functions. These are functions that are essentially overloaded on the three floating-point types (float, double, and long double) and the three complex floating-point types (complex float, complex double, and complex long double). To use them, the header file must be included; the functions are defined as macros, presumably replaced by implementation-defined names.

For example, the following is one possible implementation of the type-generic functions:

(Support for type-generic mathematical functions might be provided by many C++ implementations as an extension, although the exact nature of such generic/overloaded functions would most likely differ substantially from the corresponding C99 implementation. In particular, pointers to type-generic functions would probably behave differently.)

type = i + t + sizeof(type); s.memb = type; } This difference in the treatment of typedefs can also lead to code that is valid as both C and C++, but which has different semantic behavior. For example:

Variable-argument function declaratorsC90 syntax allows a trailing ellipsis in the parameter list of a function declarator, which specifies that the function can take zero or more additional arguments after the last named parameter.

C++ also allows variable function argument lists, but provides two syntactical forms for this feature.

Variable-argument preprocessor function macrosC99 supports preprocessor function macros that may take a variable number of arguments. Such macros are defined with a trailing '...' token in their parameter lists, and may use the __VA_ARGS__ reserved identifier in their replacement text.

(This feature is likely to be provided as an extension by many C++ compilers.)

[C99: §6.10.3, 6.10.3.1, 6.10.3.4, 6.10.3.5] [C++98: §16.3, 16.3.1]

Variable-length arrays (VLAs)C99 supports variable-length arrays, which are arrays of automatic storage whose size is determined dynamically at program execution time. For example:

size_t sum(int sz) { float arr[sz]; // VLA, dynamically allocated

while (sz-- > 0) arr[sz] = sz; return sizeof(arr); // Evaluated at runtime } C99 also provides new declaration syntax for function parameters of VLA types, allowing a variable identifier or a '*' to occur within the brackets of an array function parameter declaration in place of a constant integer size expression. The following example illustrates the syntax involved in passing VLAs to a function:

extern float sum_square(int n, float a[*]);

float sum_cube(int n, float a[m]) { ... }

void add_seq(int n) { float x[n]; // VLA float s;

... s = sum_square(n, x) + sum_cube(n, x); ... } VLA function parameter declarations using a '*' can only appear in function declarations (with prototypes) and not in function definitions. Note that this capability also affects the way sizeof expressions are evaluated.

C++ does not support VLAs.

[C99: §6.7.5, 6.7.5.2, 6.7.5.3, 6.7.6] [C++98: §8.3.4, 8.3.5, 8.4]

Void pointer assignmentsC allows a pointer to void (void *) value to be assigned to an object of any other pointer type without requiring a cast. This allows such things as assigning the return value of malloc() to a pointer variable without the need for an explicit cast.

C++ does not allow assigning a pointer to void directly to an object of any other pointer type without an explicit cast. This is considered a breach of type safety, so an explicit cast is required. Thus the following code is valid C but invalid C++:

(Note that there are situations in C++ where pointers are implicitly converted to type pointer to void, such as when comparing a pointer of type pointer to void to another pointer of a different type, but such situations are considered type safe since no pointer objects are modified in the process.)

Wide character typeC provides a wide character type, wchar_t, that is capable of holding a single wide character from an extended character set. This type is defined in the standard header files , , and .

C++ also provides a wchar_t type, but it is a reserved keyword just like int. No header file is required to enable its definition.

This means that C code that does not include any of the standard header files listed above is free to use wchar_t as an identifier or macro name; such code will not compile as C++ code.

// Does not #include , , or

typedef unsigned short wchar_t;

wchar_t readwc(void) { ... } The recommended practice is therefore to use the wchar_t type only for its special meaning, and only after including , , or .

(It is likely that a header will be provided by most C++ implementations as an extension. Some C++ compilers might also provide an empty header as an extension.)

My thanks to the the people who gave helpful comments on early drafts of this document, especially to the following individuals who emailed me suggestions and corrections or posted comments on the comp.std.c and comp.std.c++ newsgroups: