______________________________________________________________________
Annex 0 (informative)
Compatibility [diff]
______________________________________________________________________
1.1 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.
1.1.1 Clause _lex_: lexical conventions [diff.lex]
_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.
_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 fea-
ture. Any ISO C programs that used any of these keywords as identi-
fiers 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.
_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.
Subclause _lex.string:
4 Change: String literals made const
The type of a string literal is changed from "array of char" to "array
of const char." The type of a wide string literal is changed from
"array of wchar_t" to "array of const wchar_t."
Rationale: This avoids calling an inappropriate overloaded function,
which might expect to be able to modify its argument.
Effect on original feature: Change to semantics of well-defined fea-
ture.
Difficulty of converting: Simple syntactic transformation, because
string literals can be converted to char*; (_conv.array_). The most
common cases are handled by a new but deprecated standard conversion:
char* p = "abc"; // valid in C, deprecated in C++
char* q = expr ? "abc" : "de"; // valid in C, invalid in C++
How widely used: Programs that have a legitimate reason to treat
string literals as pointers to potentially modifiable memory are prob-
ably rare.
1.1.2 Clause _basic_: basic concepts [diff.basic]
_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.
_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.
_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
_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
_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
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 Inter-
national Standard.
How widely used: Common.
_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.
_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.
1.1.3 Clause _expr_: expressions [diff.expr]
_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 commer-
cially.
How widely used: Common.
_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.
1.1.4 Clause _stmt.stmt_: statements [diff.stat]
_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: Semantic transformation.
How widely used: Seldom.
_stmt.return_
2 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 on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. Add an appropriate
return value to the source code, e.g. zero.
How widely used: Seldom. For several years, many existing C implemen-
tations have produced warnings in this case.
1.1.5 Clause _dcl.dcl_: declarations [diff.dcl]
_dcl.stc_
1 Change: In C++, the static or extern specifiers can only be applied to
names of objects or functions
Using these specifiers with type declarations is illegal in C++. In
C, these specifiers are ignored when used on type declarations. Exam-
ple:
static struct S { // valid C, invalid in C++
int i;
// ...
};
Rationale: Storage class specifiers don't have any meaning when asso-
ciated with a type. In C++, class members can be defined with the
static storage class specifier. Allowing storage class specifiers on
type declarations could render the code confusing for users.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Syntactic transformation.
How widely used: Seldom.
_dcl.typedef_
2 Change: A C++ typedef name must be different from any class type name
declared in the same scope (except if the typedef is a synonym of the
class name with the same name). In C, a typedef name and a struct tag
name declared in the same scope can have the same name (because they
have different name spaces)
Example:
typedef struct name1 { /*...*/ } name1; // valid C and C++
struct name { /*...*/ };
typedef int name; // valid C, invalid C++
Rationale: For ease of use, C++ doesn't require that a type name be
prefixed with the keywords class, struct or union when used in object
declarations or type casts. Example:
class name { /*...*/ };
name i; // i has type class name
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. One of the 2 types
has to be renamed.
How widely used: Seldom.
_dcl.type_ [see also _basic.link_]
3 Change: const objects must be initialized in C++ but can be left
uninitialized in C
Rationale: A const object cannot be assigned to so it must be initial-
ized to hold a useful value.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation.
How widely used: Seldom.
_dcl.type_ (type specifiers)
4 Change: Banning implicit int
In C++ a decl-specifier-seq must contain a type-specifier. In the
following example, the left-hand column presents valid C; the right-
hand column presents equivalent C++:
void f(const parm); void f(const int parm);
const n = 3; const int n = 3;
main() int main()
/* ... */ /* ... */
Rationale: In C++, implicit int creates several opportunities for
ambiguity between expressions involving function-like casts and decla-
rations. Explicit declaration is increasingly considered to be proper
style. Liaison with WG14 (C) indicated support for (at least) depre-
cating implicit int in the next revision of C.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Syntactic transformation. Could be auto-
mated.
How widely used: Common.
_dcl.enum_
5 Change: C++ objects of enumeration type can only be assigned values of
the same enumeration type. In C, objects of enumeration type can be
assigned values of any integral type
Example:
enum color { red, blue, green };
color c = 1; // valid C, invalid C++
Rationale: The type-safe nature of C++.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Syntactic transformation. (The type error
produced by the assignment can be automatically corrected by applying
an explicit cast.)
How widely used: Common.
_dcl.enum_
6 Change: In C++, the type of an enumerator is its enumeration. In C,
the type of an enumerator is int.
Example:
enum e { A };
sizeof(A) == sizeof(int) // in C
sizeof(A) == sizeof(e) // in C++
/* and sizeof(int) is not necessary equal to sizeof(e) */
Rationale: In C++, an enumeration is a distinct type.
Effect on original feature: Change to semantics of well-defined fea-
ture.
Difficulty of converting: Semantic transformation.
How widely used: 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.
1.1.6 Clause _dcl.decl_: declarators [diff.decl]
_dcl.fct_
1 Change: In C++, 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:
int f(); // means int f(void) in C++
// int f(unknown) in C
Rationale: This is to avoid erroneous function calls (i.e. function
calls with the wrong number or type of arguments).
Effect on original feature: Change to semantics of well-defined fea-
ture. This feature was marked as "obsolescent" in C.
Difficulty of converting: Syntactic transformation. The function dec-
larations 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 argu-
ments differed.
How widely used: Common.
_dcl.fct_ [see _expr.sizeof_]
2 Change: In C++, types may not be defined in return or parameter types.
In C, these type definitions are allowed
Example:
void f( struct S { int a; } arg ) {} // valid C, invalid C++
enum E { A, B, C } f() {} // valid C, invalid C++
Rationale: When comparing types in different compilation units, C++
relies on name equivalence when C relies on structural equivalence.
Regarding parameter types: since the type defined in an parameter list
would be in the scope of the function, the only legal calls in C++
would be from within the function itself.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. The type defini-
tions must be moved to file scope, or in header files.
How widely used: Seldom. This style of type definitions is seen as
poor coding style.
_dcl.fct.def_
3 Change: In C++, the syntax for function definition excludes the "old-
style" C function. In C, "old-style" syntax is allowed, but deprecated
as "obsolescent."
Rationale: Prototypes are essential to type safety.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Syntactic transformation.
How widely used: Common in old programs, but already known to be obso-
lescent.
_dcl.init.string_
4 Change: In C++, when initializing an array of character with a string,
the number of characters in the string (including the terminating
'\0') must not exceed the number of elements in the array. In C, an
array can be initialized with a string even if the array is not large
enough to contain the string terminating '\0'
Example:
char array[4] = "abcd"; // valid C, invalid C++
Rationale: When these non-terminated arrays are manipulated by stan-
dard string routines, there is potential for major catastrophe.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. The arrays must be
declared one element bigger to contain the string terminating '\0'.
How widely used: Seldom. This style of array initialization is seen
as poor coding style.
1.1.7 Clause _class_: classes [diff.class]
_class.name_ [see also _dcl.typedef_]
1 Change: In C++, a class declaration introduces the class name into the
scope where it is declared and hides any object, function or other
declaration of that name in an enclosing scope. In C, an inner scope
declaration of a struct tag name never hides the name of an object or
function in an outer scope
Example:
int x[99];
void f()
{
struct x { int a; };
sizeof(x); /* size of the array in C */
/* size of the struct in C++ */
}
Rationale: This is one of the few incompatibilities between C and C++
that can be attributed to the new C++ name space definition where a
name can be declared as a type and as a nontype in a single scope
causing the nontype name to hide the type name and requiring that the
keywords class, struct, union or enum be used to refer to the type
name. This new name space definition provides important notational
conveniences to C++ programmers and helps making the use of the user-
defined types as similar as possible to the use of built-in types.
The advantages of the new name space definition were judged to out-
weigh by far the incompatibility with C described above.
Effect on original feature: Change to semantics of well-defined fea-
ture.
Difficulty of converting: Semantic transformation. If the hidden name
that needs to be accessed is at global scope, the :: C++ operator can
be used. If the hidden name is at block scope, either the type or the
struct tag has to be renamed.
How widely used: Seldom.
_class.nest_
2 Change: In C++, the name of a nested class is local to its enclosing
class. In C the name of the nested class belongs to the same scope as
the name of the outermost enclosing class
Example:
struct X {
struct Y { /* ... */ } y;
};
struct Y yy; // valid C, invalid C++
Rationale: C++ classes have member functions which require that
classes establish scopes. The C rule would leave classes as an incom-
plete scope mechanism which would prevent C++ programmers from main-
taining locality within a class. A coherent set of scope rules for
C++ based on the C rule would be very complicated and C++ programmers
would be unable to predict reliably the meanings of nontrivial exam-
ples involving nested or local functions.
Effect on original feature: Change of semantics of well-defined fea-
ture.
Difficulty of converting: 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:
struct Y; // struct Y and struct X are at the same scope
struct X {
struct Y { /* ... */ } y;
};
All the definitions of C struct types enclosed in other struct defini-
tions and accessed outside the scope of the enclosing struct could be
exported to the scope of the enclosing struct. Note: this is a conse-
quence of the difference in scope rules, which is documented in
_basic.scope_.
How widely used: Seldom.
_class.nested.type_
3 Change: In C++, a typedef name may not be redefined in a class decla-
ration after being used in the declaration
Example:
typedef int I;
struct S {
I i;
int I; // valid C, invalid C++
};
Rationale: When classes become complicated, allowing such a redefini-
tion after the type has been used can create confusion for C++ pro-
grammers as to what the meaning of 'I' really is.
Effect on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. Either the type or
the struct member has to be renamed.
How widely used: Seldom.
1.1.8 Clause _special_: special member functions [diff.special]
_class.copy_ (copying class objects)
1 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:
struct X { int i; };
struct X x1, x2;
volatile struct X x3 = {0};
x1 = x3; // invalid C++
x2 = x3; // also invalid C++
Rationale: Several alternatives were debated at length. Changing the
parameter to volatile const 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 on original feature: Deletion of semantically well-defined fea-
ture.
Difficulty of converting: Semantic transformation. If volatile seman-
tics are required for the copy, a user-declared constructor or assign-
ment must be provided. If non-volatile semantics are required, an
explicit const_cast can be used.
How widely used: Seldom.
1.1.9 Clause _cpp_: preprocessing directives [diff.cpp]
_cpp.predefined_ (predefined names)
1 Change: Whether __STDC__ is defined and if so, what its value is, are
implementation-defined
Rationale: C++ is not identical to ISO C. Mandating that __STDC__ be
defined would require that translators make an incorrect claim. Each
implementation must choose the behavior that will be most useful to
its marketplace.
Effect on original feature: Change to semantics of well-defined fea-
ture.
Difficulty of converting: Semantic transformation.
How widely used: Programs and headers that reference __STDC__ are
quite common.
1.2 Standard C library [diff.library]
1 This subclause summarizes the contents of the C++ Standard library
included from the Standard C library. It also summarizes the explicit
changes in definitions, declarations, or behavior from the ISO/IEC
9899:1990 and ISO/IEC 9899:1990/DAM 1 noted in other subclauses
(_lib.headers_, _lib.support.types_, _lib.c.strings_).
2 The C++ Standard library provides 54 standard macros from the C
library, as shown in Table 1.
3 The header names (enclosed in < and >) indicate that the macro may be
defined in more than one header. All such definitions are equivalent
(_basic.def.odr_).
Table 1--Standard Macros
+----------------------------------------------------------------------------+
|assert HUGE_VAL NULL <cstring> SIGILL va_arg |
|BUFSIZ LC_ALL NULL <ctime> SIGINT va_end |
|CLOCKS_PER_SEC LC_COLLATE NULL <cwchar> SIGSEGV va_start |
|EDOM LC_CTYPE offsetof SIGTERM WCHAR_MAX |
|EOF LC_MONETARY RAND_MAX SIG_DFL WCHAR_MIN |
|ERANGE LC_NUMERIC SEEK_CUR SIG_ERR WEOF <cwchar> |
|errno LC_TIME SEEK_END SIG_IGN WEOF <cwctype> |
|EXIT_FAILURE L_tmpnam SEEK_SET stderr _IOFBF |
|EXIT_SUCCESS MB_CUR_MAX setjmp stdin _IOLBF |
|FILENAME_MAX NULL <cstddef> SIGABRT stdout _IONBF |
|FOPEN_MAX NULL <cstdio> SIGFPE TMP_MAX |
+----------------------------------------------------------------------------+
4 The C++ Standard library provides 45 standard values from the C
library, as shown in Table 2:
Table 2--Standard Values
+---------------------------------------------------------------+
|CHAR_BIT FLT_DIG INT_MIN MB_LEN_MAX |
|CHAR_MAX FLT_EPSILON LDBL_DIG SCHAR_MAX |
|CHAR_MIN FLT_MANT_DIG LDBL_EPSILON SCHAR_MIN |
|DBL_DIG FLT_MAX LDBL_MANT_DIG SHRT_MAX |
|DBL_EPSILON FLT_MAX_10_EXP LDBL_MAX SHRT_MIN |
|DBL_MANT_DIG FLT_MAX_EXP LDBL_MAX_10_EXP UCHAR_MAX |
|DBL_MAX FLT_MIN LDBL_MAX_EXP UINT_MAX |
|DBL_MAX_10_EXP FLT_MIN_10_EXP LDBL_MIN ULONG_MAX |
|DBL_MAX_EXP FLT_MIN_EXP LDBL_MIN_10_EXP USHRT_MAX |
|DBL_MIN FLT_RADIX LDBL_MIN_EXP |
|DBL_MIN_10_EXP FLT_ROUNDS LONG_MAX |
|DBL_MIN_EXP INT_MAX LONG_MIN |
+---------------------------------------------------------------+
5 The C++ Standard library provides 19 standard types from the C
library, as shown in Table 3:
Table 3--Standard Types
+-----------------------------------------------------------------+
|clock_t ldiv_t size_t <cstdio> wctrans_t |
|div_t mbstate_t size_t <cstring> wctype_t |
|FILE ptrdiff_t size_t <ctime> wint_t <cwchar> |
|fpos_t sig_atomic_t time_t wint_t <cwctype> |
|jmp_buf size_t <cstddef> va_list |
+-----------------------------------------------------------------+
6 The C++ Standard library provides 2 standard structures from the C
library, as shown in Table 4:
Table 4--Standard Structs
+-----------+
|lconv tm |
+-----------+
7 The C++ Standard library provides 209 standard functions from the C
library, as shown in Table 5:
Table 5--Standard Functions
+---------------------------------------------------------------------------------+
|abort fgetpos gmtime log10 rename strtok wcscpy |
|abs fgets isalnum longjmp rewind strtol wcscspn |
|acos fgetwc isalpha malloc scanf strtoul wcsftime |
|asctime fgetws iscntrl mblen setbuf strxfrm wcslen |
|asin floor isdigit mbrlen setlocale swprintf wcsncat |
|atan fmod isgraph mbrtowc setvbuf swscanf wcsncmp |
|atan2 fopen islower mbsinit signal system wcsncpy |
|atexit fprintf isprint mbsrtowcs sin tan wcspbrk |
|atof fputc ispunct mbstowcs sinh tanh wcsrchr |
|atoi fputs isspace mbtowc sprintf time wcsrtombs |
|atol fputwc isupper memchr sqrt tmpfile wcsspn |
|bsearch fputws iswalnum memcmp srand tmpnam wcsstr |
|btowc fread iswalpha memcpy sscanf tolower wcstod |
|calloc free iswcntrl memmove strcat toupper wcstok |
|ceil freopen iswctype memset strchr towctrans wcstol |
|clearerr frexp iswdigit mktime strcmp towlower wcstombs |
|clock fscanf iswgraph modf strcoll towupper wcstoul |
|cos fseek iswlower perror strcpy ungetc wcsxfrm |
|cosh fsetpos iswprint pow strcspn ungetwc wctob |
|ctime ftell iswpunct printf strerror vfprintf wctomb |
|difftime fwide iswspace putc strftime vfwprintf wctrans |
|div fwprintf iswupper putchar strlen vprintf wctype |
|exit fwrite iswxdigit puts strncat vsprintf wmemchr |
|exp fwscanf isxdigit putwc strncmp vswprintf wmemcmp |
|fabs getc labs putwchar strncpy vwprintf wmemcpy |
|fclose getchar ldexp qsort strpbrk wcrtomb wmemmove |
|feof getenv ldiv raise strrchr wcscat wmemset |
|ferror gets localeconv rand strspn wcschr wprintf |
|fflush getwc localtime realloc strstr wcscmp wscanf |
|fgetc getwchar log remove strtod wcscoll |
+---------------------------------------------------------------------------------+
1.2.1 Modifications to headers [diff.mods.to.headers]
1 For compatibility with the Standard C library, the C++ Standard
library provides the 18 C headers (_depr.c.headers_), but their use is
deprecated in C++.
1.2.2 Modifications to definitions [diff.mods.to.definitions]
1.2.2.1 Type wchar_t [diff.wchar.t]
1 wchar_t is a keyword in this International Standard (_lex.key_). It
does not appear as a type name defined in any of <cstddef>, <cstdlib>,
or <cwchar> (_lib.c.strings_).
1.2.2.2 Header <iso646.h> [diff.header.iso646.h]
1 The tokens and, and_eq, bitand, bitor, compl, not_eq, not, or, or_eq,
xor, and xor_eq are keywords in this International Standard
(_lex.key_). They do not appear as macro names defined in <ciso646>.
1.2.2.3 Macro NULL [diff.null]
1 The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>,
<cstdlib>, <cstring>, <ctime>, or <cwchar>, is an implementation-
defined C++ null pointer constant in this International Standard
(_lib.support.types_).
1.2.3 Modifications to declarations [diff.mods.to.declarations]
1 Header <cstring>: The following functions have different declarations:
--strchr
--strpbrk
--strrchr
--strstr
--memchr
2 _lib.c.strings_ describes the changes.
1.2.4 Modifications to behavior [diff.mods.to.behavior]
1 Header <cstdlib>: The following functions have different behavior:
--atexit
--exit
--abort
_lib.support.start.term_ describes the changes.
2 Header <csetjmp>: The following functions have different behavior:
--longjmp
_lib.support.runtime_ describes the changes.
1.2.4.1 Macro offsetof(type, member-designator) [diff.offsetof]
1 The macro offsetof, defined in <cstddef>, accepts a restricted set of
type arguments in this International Standard. _lib.support.types_
describes the change.
1.2.4.2 Memory allocation functions [diff.malloc]
1 The functions calloc, malloc, and realloc are restricted in this
International Standard. _lib.c.malloc_ describes the changes.