%!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>},
\tcode{<chrono>},
\tcode{<codecvt>},
\tcode{<condition_variable>},
\tcode{<forward_list>},
\tcode{<future>},
\tcode{<initializer_list>},
\tcode{<mutex>},
\tcode{<random>},
\tcode{<ratio>},
\tcode{<regex>},
\tcode{<scoped_allocator>},
\tcode{<system_error>},
\tcode{<thread>},
\tcode{<tuple>},
\tcode{<typeindex>},
\tcode{<type_traits>},\\
\tcode{<unordered_map>},
and
\tcode{<unordered_set>}.
In addition the following C compatibility headers are new:
\tcode{<ccomplex>},
\tcode{<cfenv>},
\tcode{<cinttypes>},
\tcode{<cstdalign>},
\tcode{<cstdbool>},
\tcode{<cstdint>},
\tcode{<ctgmath>},
and
\tcode{<cuchar>}.
Valid \CppIII code that \tcode{\#include}{s} headers with these names may be
invalid in this International Standard.

\ref{swappable.requirements}
\effect Function \tcode{swap} moved to a different header
\rationale Remove dependency on \tcode{<algorithm>} for \tcode{swap}.
\effect Valid \CppIII code that has been compiled expecting swap to be in
\tcode{<algorithm>} may have to instead include \tcode{<utility>}.

\ref{namespace.posix}
\change New reserved namespace
\rationale New functionality.
\effect
The global namespace \tcode{posix} is now reserved for standardization. Valid
\CppIII code that uses a top-level namespace \tcode{posix} may be invalid in
this International Standard.

\ref{res.on.macro.definitions}
\change Additional restrictions on macro names
\rationale Avoid hard to diagnose or non-portable constructs.
\effect
Names of attribute identifiers may not be used as macro names. Valid \Cpp
2003 code that defines \tcode{override}, \tcode{final},
\tcode{carries_dependency}, or \tcode{noreturn} as macros is invalid in this
International Standard.

\rSec2[diff.cpp03.language.support]{Clause \ref{language.support}:
language support library}

\ref{new.delete.single}
\change Linking \tcode{new} and \tcode{delete} operators
\rationale The two throwing single-object signatures of \tcode{operator new} and
\tcode{operator delete} are now specified to form the base functionality for
the other operators. This clarifies that replacing just these two signatures
changes others, even if they are not explicitly changed.
\effect
Valid \CppIII code that replaces global \tcode{new} or \tcode{delete}
operators may execute differently in this International Standard. For
example, the following program should write \tcode{"custom deallocation"} twice,
once for the single-object delete and once for the array delete.

\begin{codeblock}
#include <cstdio>
#include <cstdlib>
#include <new>

void* operator new(std::size_t size) throw(std::bad_alloc) {
  return std::malloc(size);
}

void operator delete(void* ptr) throw() {
  std::puts("custom deallocation");
  std::free(ptr);
}

int main() {
  int* i = new int;
  delete i;                     // single-object delete
  int* a = new int[3];
  delete [] a;                  // array delete
  return 0;
}
\end{codeblock}

\ref{new.delete.single}
\change \tcode{operator new} may throw exceptions other than
\tcode{std::bad_alloc}
\rationale Consistent application of \tcode{noexcept}.
\effect
Valid \CppIII code that assumes that global \tcode{operator new} only
throws \tcode{std::bad_alloc} may execute differently in this International
Standard.

\rSec2[diff.cpp03.diagnostics]{Clause \ref{diagnostics}: diagnostics library}

\ref{errno}
\change Thread-local error numbers
\rationale Support for new thread facilities.
\effect Valid but implementation-specific \CppIII code that relies on
\tcode{errno} being the same across threads may change behavior in this
International Standard.

\rSec2[diff.cpp03.utilities]{Clause \ref{utilities}: general utilities library}

\ref{util.dynamic.safety}
\change Minimal support for garbage-collected regions
\rationale Required by new feature.
\effect
Valid \CppIII code, compiled without traceable pointer support,
that interacts with newer \Cpp code using regions declared reachable may
have different runtime behavior.

\ref{refwrap}, \ref{arithmetic.operations}, \ref{comparisons},
\ref{logical.operations}, \ref{bitwise.operations}, \ref{negators}
\change Standard function object types no longer derived from
\tcode{std::unary_function} or \tcode{std::binary_function}
\rationale Superseded by new feature.
\effect
Valid \CppIII code that depends on function object types being derived from
\tcode{unary_function} or \tcode{binary_function} will execute differently
in this International Standard.

\rSec2[diff.cpp03.strings]{Clause \ref{strings}: strings library}

\ref{string.classes}
\change \tcode{basic_string} requirements no longer allow reference-counted
strings
\rationale Invalidation is subtly different with reference-counted strings.
This change regularizes behavior for this International Standard.
\effect
Valid \CppIII code may execute differently in this International Standard.

\ref{string.require}
\change Loosen \tcode{basic_string} invalidation rules
\rationale Allow small-string optimization.
\effect
Valid \CppIII code may execute differently in this International Standard.
Some \tcode{const} member functions, such as \tcode{data} and \tcode{c_str},
no longer invalidate iterators.

\rSec2[diff.cpp03.containers]{Clause \ref{containers}: containers library}

\ref{container.requirements}
\change Complexity of \tcode{size()} member functions now constant
\rationale Lack of specification of complexity of \tcode{size()} resulted in
divergent implementations with inconsistent performance characteristics.
\effect
Some container implementations that conform to \CppIII may not conform to the
specified \tcode{size()} requirements in this International Standard. Adjusting
containers such as \tcode{std::list} to the stricter requirements may require
incompatible changes.

\ref{container.requirements}
\change Requirements change: relaxation
\rationale Clarification.
\effect
Valid \CppIII code that attempts to meet the specified container requirements
may now be over-specified. Code that attempted to be portable across containers
may need to be adjusted as follows:
\begin{itemize}
\item not all containers provide \tcode{size()}; use \tcode{empty()} instead
of \tcode{size() == 0};
\item not all containers are empty after construction (\tcode{array});
\item not all containers have constant complexity for \tcode{swap()} (\tcode{array}).
\end{itemize}

\ref{container.requirements}
\change Requirements change: default constructible
\rationale Clarification of container requirements.
\effect
Valid \CppIII code that attempts to explicitly instantiate a container using
a user-defined type with no default constructor may fail to compile.

\ref{sequence.reqmts}, \ref{associative.reqmts}
\change Signature changes: from \tcode{void} return types
\rationale Old signature threw away useful information that may be expensive
to recalculate.
\effect
The following member functions have changed:
\begin{itemize}
\item \tcode{erase(iter)} for \tcode{set}, \tcode{multiset}, \tcode{map}, \tcode{multimap}
\item \tcode{erase(begin, end)} for \tcode{set}, \tcode{multiset}, \tcode{map}, \tcode{multimap}
\item \tcode{insert(pos, num, val)} for \tcode{vector}, \tcode{deque}, \tcode{list}, \tcode{forward_list}
\item \tcode{insert(pos, beg, end)} for \tcode{vector}, \tcode{deque}, \tcode{list}, \tcode{forward_list}
\end{itemize}

Valid \CppIII code that relies on these functions returning \tcode{void}
(e.g., code that creates a pointer to member function that points to one
of these functions) will fail to compile with this International Standard.

\ref{sequence.reqmts}, \ref{associative.reqmts}
\change Signature changes: from \tcode{iterator} to \tcode{const_iterator}
parameters
\rationale Overspecification.
\effects
The signatures of the following member functions changed from taking an
\tcode{iterator} to taking a \tcode{const_iterator}:

\begin{itemize}
\item \tcode{insert(iter, val)} for \tcode{vector}, \tcode{deque}, \tcode{list},
\tcode{set}, \tcode{multiset}, \tcode{map}, \tcode{multimap}
\item \tcode{insert(pos, beg, end)} for \tcode{vector}, \tcode{deque}, \tcode{list},
\tcode{forward_list}
\item \tcode{erase(iter)} for \tcode{set}, \tcode{multiset}, \tcode{map}, \tcode{multimap}
\item \tcode{erase(begin, end)} for \tcode{set}, \tcode{multiset}, \tcode{map}, \tcode{multimap}
\item all forms of \tcode{list::splice}
\item all forms of \tcode{list::merge}
\end{itemize}

Valid \CppIII code that uses these functions may fail to compile with this
International Standard.

\ref{sequence.reqmts}, \ref{associative.reqmts}
\change Signature changes: \tcode{resize}
\rationale Performance, compatibility with move semantics.
\effect
For \tcode{vector}, \tcode{deque}, and \tcode{list}
the fill value passed to \tcode{resize} is now passed by reference instead of
by value, and an additional overload of \tcode{resize} has been added. Valid
\CppIII code that uses this function may fail to compile with this International
Standard.

\rSec2[diff.cpp03.algorithms]{Clause \ref{algorithms}: algorithms library}

\ref{algorithms.general}
\change Result state of inputs after application of some algorithms
\rationale Required by new feature.
\effect
A valid \CppIII program may detect that an object with a valid but
unspecified state has a different valid but unspecified state with this
International Standard. For example, \tcode{std::remove} and
\tcode{std::remove_if} may leave the tail of the input sequence with a
different set of values than previously.

\rSec2[diff.cpp03.numerics]{Clause \ref{numerics}: numerics library}

\ref{complex.numbers}
\change Specified representation of complex numbers
\rationale Compatibility with C99.
\effect
Valid \CppIII code that uses implementation-specific knowledge about the
binary representation of the required template specializations of
\tcode{std::complex} may not be compatible with this International Standard.

\rSec2[diff.cpp03.input.output]{Clause \ref{input.output}: Input/output library}

\ref{istream::sentry},
\ref{ostream::sentry},
\ref{iostate.flags}
\change Specify use of explicit in existing boolean conversion operators
\rationale Clarify intentions, avoid workarounds.
\effect
Valid \CppIII code that relies on implicit boolean conversions will fail to
compile with this International Standard. Such conversions occur in the
following conditions:

\begin{itemize}
\item passing a value to a function that takes an argument of type \tcode{bool};
\item using \tcode{operator==} to compare to \tcode{false} or \tcode{true};
\item returning a value from a function with a return type of \tcode{bool};
\item initializing members of type \tcode{bool} via aggregate initialization;
\item initializing a \tcode{const bool\&} which would bind to a temporary.
\end{itemize}

\ref{ios::failure}
\change Change base class of \tcode{std::ios_base::failure}
\rationale More detailed error messages.
\effect
\tcode{std::ios_base::failure} is no longer derived directly from
\tcode{std::exception}, but is now derived from \tcode{std::system_error},
which in turn is derived from \tcode{std::runtime_error}. Valid \CppIII code
that assumes that \tcode{std::ios_base::failure} is derived directly from
\tcode{std::exception} may execute differently in this International Standard.

\ref{ios.base}
\change Flag types in \tcode{std::ios_base} are now bitmasks with values
defined as constexpr static members
\rationale Required for new features.
\effect
Valid \CppIII code that relies on \tcode{std::ios_base} flag types being
represented as \tcode{std::bitset} or as an integer type may fail to compile
with this International Standard. For example:

\begin{codeblock}
#include <iostream>

int main() {
  int flag = std::ios_base::hex;
  std::cout.setf(flag);         // error: \tcode{setf} does not take argument of type \tcode{int}
  return 0;
}
\end{codeblock}

\rSec1[diff.cpp11]{\Cpp and ISO \CppXI}

\pnum
\indextext{summary!compatibility~with ISO \CppXI}%
This subclause lists the differences between \Cpp and
ISO \CppXI (ISO/IEC 14882:2011, \doccite{Programming Languages --- \Cpp}),
by the chapters of this document.

\rSec2[diff.cpp11.lex]{Clause \ref{lex}: lexical conventions}

\ref{lex.ppnumber}
\change \grammarterm{pp-number} can contain one or more single quotes.
\rationale Necessary to enable single quotes as digit separators.
\effect Valid \CppXI code may fail to compile or may change meaning in this
International Standard. For example, the following code is valid both in \CppXI and in
this International Standard, but the macro invocation produces different outcomes
because the single quotes delimit a character literal in \CppXI, whereas they are digit
separators in this International Standard:

\begin{codeblock}
#define M(x, ...) __VA_ARGS__
int x[2] = { M(1'2,3'4) };
// \tcode{int x[2] = \{\};\ \ \ \ \ } --- \CppXI
// \tcode{int x[2] = \{ 3'4 \};} --- this International Standard
\end{codeblock}

\rSec2[diff.cpp11.basic]{Clause \ref{basic}: basic concepts}

\ref{basic.stc.dynamic.deallocation}
\change New usual (non-placement) deallocator 
\rationale Required for sized deallocation.
\effect Valid \CppXI code could declare a global placement allocation function and
deallocation function as follows:

\begin{codeblock}
void operator new(std::size_t, std::size_t);
void operator delete(void*, std::size_t) noexcept;
\end{codeblock}

In this International Standard, however, the declaration of \tcode{operator delete}
might match a predefined usual (non-placement)
\tcode{operator delete}~(\ref{basic.stc.dynamic}). If so, the
program is ill-formed, as it was for class member allocation functions and
deallocation functions~(\ref{expr.new}).

\rSec2[diff.cpp11.dcl.dcl]{Clause \ref{dcl.dcl}: declarations}

\ref{dcl.constexpr}
\change \tcode{constexpr} non-static member functions are not implicitly
\tcode{const} member functions.
\rationale Necessary to allow \tcode{constexpr} member functions to mutate
the object.
\effect
Valid \CppXI code may fail to compile in this International Standard.
For example, the following code is valid in \CppXI
but invalid in this International Standard because it declares the same member
function twice with different return types:

\begin{codeblock}
struct S {
  constexpr const int &f();
  int &f();
};
\end{codeblock}

\rSec2[diff.cpp11.input.output]{Clause \ref{input.output}: input/output library}

\ref{c.files}
\change \tcode{gets} is not defined.
\rationale Use of \tcode{gets} is considered dangerous.
\effect
Valid \CppXI code that uses the \tcode{gets} function may fail to compile
in this International Standard.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\rSec1[diff.library]{C standard library}
\indextext{library!C standard}%

\pnum
This subclause summarizes the contents of the \Cpp standard library
included from the Standard C library.
It also summarizes the explicit changes in definitions,
declarations, or behavior from the Standard C library
noted in other subclauses (\ref{headers}, \ref{support.types}, \ref{c.strings}).

\pnum
The \Cpp standard library provides 57 standard macros from the C library,
as shown in Table~\ref{tab:diff.standard.macros}.

\pnum
The header names (enclosed in
\tcode{<}
and
\tcode{>})
indicate that the macro may be defined in more than one header.
All such definitions are equivalent (\ref{basic.def.odr}).

\begin{floattable}{Standard macros}{tab:diff.standard.macros}
{lllll}
\hline

\tcode{assert}    &
\tcode{HUGE_VAL}  &
\tcode{NULL <cstring>}  &
\tcode{SIGINT}    &
\tcode{va_end}    \\

\tcode{BUFSIZ}    &
\tcode{LC_ALL}    &
\tcode{NULL <ctime>}  &
\tcode{SIGSEGV} &
\tcode{va_start}  \\

\tcode{CLOCKS_PER_SEC}  &
\tcode{LC_COLLATE}  &
\tcode{NULL <cwchar>} &
\tcode{SIGTERM} &
\tcode{WCHAR_MAX} \\

\tcode{EDOM}    &
\tcode{LC_CTYPE}  &
\tcode{offsetof}  &
\tcode{SIG_DFL} &
\tcode{WCHAR_MIN} \\

\tcode{EILSEQ}    &
\tcode{LC_MONETARY} &
\tcode{RAND_MAX}  &
\tcode{SIG_ERR} &
\tcode{WEOF <cwchar>} \\

\tcode{EOF}     &
\tcode{LC_NUMERIC}  &
\tcode{SEEK_CUR}  &
\tcode{SIG_IGN} &
\tcode{WEOF <cwctype>}  \\

\tcode{ERANGE}    &
\tcode{LC_TIME} &
\tcode{SEEK_END}  &
\tcode{stderr}    &
\tcode{_IOFBF}    \\

\tcode{errno}   &
\tcode{L_tmpnam}  &
\tcode{SEEK_SET}  &
\tcode{stdin}   &
\tcode{_IOLBF}    \\

\tcode{EXIT_FAILURE}  &
\tcode{MB_CUR_MAX}  &
\tcode{setjmp}    &
\tcode{stdout}    &
\tcode{_IONBF}    \\

\tcode{EXIT_SUCCESS}  &
\tcode{NULL <clocale>}  &
\tcode{SIGABRT} &
\tcode{TMP_MAX} & \\

\tcode{FILENAME_MAX}  &
\tcode{NULL <cstddef>}  &
\tcode{SIGFPE}    &
\tcode{va_arg}    & \\

\tcode{FOPEN_MAX} &
\tcode{NULL <cstdlib>}  &
\tcode{SIGILL}    &
\tcode{va_copy}   & \\


\end{floattable}

\pnum
The \Cpp standard library provides 57 standard values from the C library,
as shown in Table~\ref{tab:diff.standard.values}.

\begin{floattable}{Standard values}{tab:diff.standard.values}
{llll}
\hline
\tcode{CHAR_BIT}  &
 \tcode{FLT_DIG}  &
 \tcode{INT_MIN}  &
 \tcode{MB_LEN_MAX} \\
\tcode{CHAR_MAX}  &
 \tcode{FLT_EPSILON}  &
 \tcode{LDBL_DIG} &
 \tcode{SCHAR_MAX}  \\
\tcode{CHAR_MIN}  &
 \tcode{FLT_MANT_DIG} &
 \tcode{LDBL_EPSILON} &
 \tcode{SCHAR_MIN}  \\
\tcode{DBL_DIG}   &
 \tcode{FLT_MAX}  &
 \tcode{LDBL_MANT_DIG}  &
 \tcode{SHRT_MAX} \\
\tcode{DBL_EPSILON} &
 \tcode{FLT_MAX_10_EXP} &
 \tcode{LDBL_MAX} &
 \tcode{SHRT_MIN} \\
\tcode{DBL_MANT_DIG}  &
 \tcode{FLT_MAX_EXP}  &
 \tcode{LDBL_MAX_10_EXP}  &
 \tcode{UCHAR_MAX}  \\
\tcode{DBL_MAX}   &
 \tcode{FLT_MIN}  &
 \tcode{LDBL_MAX_EXP} &
 \tcode{UINT_MAX} \\
\tcode{DBL_MAX_10_EXP}  &
 \tcode{FLT_MIN_10_EXP} &
 \tcode{LDBL_MIN} &
 \tcode{ULONG_MAX}  \\
\tcode{DBL_MAX_EXP} &
 \tcode{FLT_MIN_EXP}  &
 \tcode{LDBL_MIN_10_EXP}&
 \tcode{USHRT_MAX} \\
\tcode{DBL_MIN}   &
 \tcode{FLT_RADIX}  &
 \tcode{LDBL_MIN_EXP} & \\
\tcode{DBL_MIN_10_EXP}  &
 \tcode{FLT_ROUNDS} &
 \tcode{LONG_MAX} & \\
\tcode{DBL_MIN_EXP} &
 \tcode{INT_MAX}  &
 \tcode{LONG_MIN} & \\ \hline
\end{floattable}

\pnum
The \Cpp standard library provides 20 standard types from the C library,
as shown in Table~\ref{tab:diff.standard.types}.

\begin{floattable}{Standard types}{tab:diff.standard.types}
{llll}
\hline
\tcode{clock_t}   &
 \tcode{ldiv_t}   &
 \tcode{size_t <cstdio>}  &
 \tcode{va_list}  \\
\tcode{div_t}   &
 \tcode{mbstate_t}  &
 \tcode{size_t <cstdlib>} &
 \tcode{wctrans_t}  \\
\tcode{FILE}    &
 \tcode{ptrdiff_t}  &
 \tcode{size_t <cstring>} &
 \tcode{wctype_t} \\
\tcode{fpos_t}    &
 \tcode{sig_atomic_t} &
 \tcode{size_t <ctime>} &
 \tcode{wint_t <cwchar>}  \\
\tcode{jmp_buf}   &
 \tcode{size_t <cstddef>} &
 \tcode{time_t}   &
 \tcode{wint_t <cwctype>} \\ \hline
\end{floattable}


\pnum
The \Cpp standard library provides 2 standard
\tcode{struct}s
from the C library,
as shown in Table~\ref{tab:diff.standard.structs}.

\begin{floattable}{Standard structs}{tab:diff.standard.structs}
{ll}
\hline
\tcode{lconv} & \tcode{tm}  \\ \hline
\end{floattable}

\pnum
The \Cpp standard library provides 209 standard functions from the C library,
as shown in Table~\ref{tab:diff.standard.functions}.

\begin{floattable}{Standard functions}{tab:diff.standard.functions}
{llllll}
\hline
\tcode{abort} &
\tcode{fmod} &
\tcode{iswalnum} &
\tcode{modf} &
\tcode{strlen} &
\tcode{wcscat} \\
\tcode{abs} &
\tcode{fopen} &
\tcode{iswalpha} &
\tcode{perror} &
\tcode{strncat} &
\tcode{wcschr} \\
\tcode{acos} &
\tcode{fprintf} &
\tcode{iswcntrl} &
\tcode{pow} &
\tcode{strncmp} &
\tcode{wcscmp} \\
\tcode{asctime} &
\tcode{fputc} &
\tcode{iswctype} &
\tcode{printf} &
\tcode{strncpy} &
\tcode{wcscoll} \\
\tcode{asin} &
\tcode{fputs} &
\tcode{iswdigit} &
\tcode{putc} &
\tcode{strpbrk} &
\tcode{wcscpy} \\
\tcode{atan} &
\tcode{fputwc} &
\tcode{iswgraph} &
\tcode{putchar} &
\tcode{strrchr} &
\tcode{wcscspn} \\
\tcode{atan2} &
\tcode{fputws} &
\tcode{iswlower} &
\tcode{puts} &
\tcode{strspn} &
\tcode{wcsftime} \\
\tcode{atexit} &
\tcode{fread} &
\tcode{iswprint} &
\tcode{putwc} &
\tcode{strstr} &
\tcode{wcslen} \\
\tcode{atof} &
\tcode{free} &
\tcode{iswpunct} &
\tcode{putwchar} &
\tcode{strtod} &
\tcode{wcsncat} \\
\tcode{atoi} &
\tcode{freopen} &
\tcode{iswspace} &
\tcode{qsort} &
\tcode{strtok} &
\tcode{wcsncmp} \\
\tcode{atol} &
\tcode{frexp} &
\tcode{iswupper} &
\tcode{raise} &
\tcode{strtol} &
\tcode{wcsncpy} \\
\tcode{bsearch} &
\tcode{fscanf} &
\tcode{iswxdigit} &
\tcode{rand} &
\tcode{strtoul} &
\tcode{wcspbrk} \\
\tcode{btowc} &
\tcode{fseek} &
\tcode{isxdigit} &
\tcode{realloc} &
\tcode{strxfrm} &
\tcode{wcsrchr} \\
\tcode{calloc} &
\tcode{fsetpos} &
\tcode{labs} &
\tcode{remove} &
\tcode{swprintf} &
\tcode{wcsrtombs} \\
\tcode{ceil} &
\tcode{ftell} &
\tcode{ldexp} &
\tcode{rename} &
\tcode{swscanf} &
\tcode{wcsspn} \\
\tcode{clearerr} &
\tcode{fwide} &
\tcode{ldiv} &
\tcode{rewind} &
\tcode{system} &
\tcode{wcsstr} \\
\tcode{clock} &
\tcode{fwprintf} &
\tcode{localeconv} &
\tcode{scanf} &
\tcode{tan} &
\tcode{wcstod} \\
\tcode{cos} &
\tcode{fwrite} &
\tcode{localtime} &
\tcode{setbuf} &
\tcode{tanh} &
\tcode{wcstok} \\
\tcode{cosh} &
\tcode{fwscanf} &
\tcode{log} &
\tcode{setlocale} &
\tcode{time} &
\tcode{wcstol} \\
\tcode{ctime} &
\tcode{getc} &
\tcode{log10} &
\tcode{setvbuf} &
\tcode{tmpfile} &
\tcode{wcstombs} \\
\tcode{difftime} &
\tcode{getchar} &
\tcode{longjmp} &
\tcode{signal} &
\tcode{tmpnam} &
\tcode{wcstoul} \\
\tcode{div} &
\tcode{getenv} &
\tcode{malloc} &
\tcode{sin} &
\tcode{tolower} &
\tcode{wcsxfrm} \\
\tcode{exit} &
\tcode{getwc} &
\tcode{mblen} &
\tcode{sinh} &
\tcode{toupper} &
\tcode{wctob} \\
\tcode{exp} &
\tcode{getwchar} &
\tcode{mbrlen} &
\tcode{sprintf} &
\tcode{towctrans} &
\tcode{wctomb} \\
\tcode{fabs} &
\tcode{gmtime} &
\tcode{mbrtowc} &
\tcode{sqrt} &
\tcode{towlower} &
\tcode{wctrans} \\
\tcode{fclose} &
\tcode{isalnum} &
\tcode{mbsinit} &
\tcode{srand} &
\tcode{towupper} &
\tcode{wctype} \\
\tcode{feof} &
\tcode{isalpha} &
\tcode{mbsrtowcs} &
\tcode{sscanf} &
\tcode{ungetc} &
\tcode{wmemchr} \\
\tcode{ferror} &
\tcode{iscntrl} &
\tcode{mbstowcs} &
\tcode{strcat} &
\tcode{ungetwc} &
\tcode{wmemcmp} \\
\tcode{fflush} &
\tcode{isdigit} &
\tcode{mbtowc} &
\tcode{strchr} &
\tcode{vfprintf} &
\tcode{wmemcpy} \\
\tcode{fgetc} &
\tcode{isgraph} &
\tcode{memchr} &
\tcode{strcmp} &
\tcode{vfwprintf} &
\tcode{wmemmove} \\
\tcode{fgetpos} &
\tcode{islower} &
\tcode{memcmp} &
\tcode{strcoll} &
\tcode{vprintf} &
\tcode{wmemset} \\
\tcode{fgets} &
\tcode{isprint} &
\tcode{memcpy} &
\tcode{strcpy} &
\tcode{vsprintf} &
\tcode{wprintf} \\
\tcode{fgetwc} &
\tcode{ispunct} &
\tcode{memmove} &
\tcode{strcspn} &
\tcode{vswprintf} &
\tcode{wscanf} \\
\tcode{fgetws} &
\tcode{isspace} &
\tcode{memset} &
\tcode{strerror} &
\tcode{vwprintf} &\\
\tcode{floor} &
\tcode{isupper} &
\tcode{mktime} &
\tcode{strftime} &
\tcode{wcrtomb} &\\ \hline
\end{floattable}

\rSec2[diff.mods.to.headers]{Modifications to headers}

\pnum
For compatibility with the Standard C library,
\indextext{library!C standard}%
the \Cpp standard library provides the C headers enumerated
in~\ref{depr.c.headers}, but their use is deprecated in \Cpp.

\rSec2[diff.mods.to.definitions]{Modifications to definitions}

\rSec3[diff.char16]{Types \tcode{char16_t} and \tcode{char32_t}}

\pnum
The types \tcode{char16_t} and \tcode{char32_t}
are distinct types rather than typedefs to existing integral types.

\rSec3[diff.wchar.t]{Type \tcode{wchar_t}}

\pnum
\tcode{wchar_t}
is a keyword in this International Standard (\ref{lex.key}).
It does not appear as a type name defined in any of
\tcode{<cstddef>},
\indexlibrary{\idxhdr{cstddef}}%
\tcode{<cstdlib>},
\indexlibrary{\idxhdr{cstdlib}}%
or
\tcode{<cwchar>}
\indexlibrary{\idxhdr{cwchar}}%
(\ref{c.strings}).

\rSec3[diff.header.iso646.h]{Header \tcode{<iso646.h>}}
\indexlibrary{\idxhdr{iso646.h}}%

\pnum
The tokens
\tcode{and},
\tcode{and_eq},
\tcode{bitand},
\tcode{bitor},
\tcode{compl},
\tcode{not_eq},
\tcode{not},
\tcode{or},
\tcode{or_eq},
\tcode{xor},
and
\tcode{xor_eq}
are keywords in this International
Standard (\ref{lex.key}).
They do not appear as macro names defined in
\tcode{<ciso646>}.
\indexlibrary{\idxhdr{ciso646}}%

\rSec3[diff.null]{Macro \tcode{NULL}}

\pnum
The macro
\tcode{NULL},
defined in any of
\indexlibrary{\idxhdr{clocale}}%
\tcode{<clocale>},
\indexlibrary{\idxhdr{cstddef}}%
\tcode{<cstddef>},
\indexlibrary{\idxhdr{cstdio}}%
\tcode{<cstdio>},
\indexlibrary{\idxhdr{cstdlib}}%
\tcode{<cstdlib>},
\indexlibrary{\idxhdr{cstring}}%
\tcode{<cstring>},
\indexlibrary{\idxhdr{ctime}}%
\tcode{<ctime>},
or
\tcode{<cw\-char>},
\indexlibrary{\idxhdr{cwchar}}%
is an implementation-defined \Cpp null pointer constant in
\indextext{implementation-defined}%
this International Standard (\ref{support.types}).

\rSec2[diff.mods.to.declarations]{Modifications to declarations}

\pnum
Header
\tcode{<cstring>}:
\indexlibrary{\idxhdr{cstring}}%
The following functions have different declarations:
\begin{itemize}
\item
\tcode{strchr}
\item
\tcode{strpbrk}
\item
\tcode{strrchr}
\item
\tcode{strstr}
\item
\tcode{memchr}
\end{itemize}

\ref{c.strings} describes the changes.

\rSec2[diff.mods.to.behavior]{Modifications to behavior}

\pnum
Header
\tcode{<cstdlib>}:
The following functions have different behavior:
\begin{itemize}
\item
\tcode{atexit}
\item
\tcode{exit}
\item
\tcode{abort}
\end{itemize}

\ref{support.start.term} describes the changes.

\pnum
Header
\tcode{<csetjmp>}:
The following functions have different behavior:
\begin{itemize}
\item
\tcode{longjmp}
\end{itemize}

\ref{support.runtime} describes the changes.

\rSec3[diff.offsetof]{Macro \tcode{offsetof(type, member-designator)}}
\indexlibrary{\idxcode{offsetof}}%

\pnum
The macro
\tcode{offsetof},
defined in
\indexlibrary{\idxhdr{cstddef}}%
\tcode{<cstddef>},
accepts a restricted set of \tcode{type} arguments in this International Standard.
\ref{support.types} describes the change.

\rSec3[diff.malloc]{Memory allocation functions}

\pnum
The functions
\indexlibrary{\idxcode{calloc}}%
\tcode{calloc},
\indexlibrary{\idxcode{malloc}}%
\tcode{malloc},
and
\indexlibrary{\idxcode{realloc}}%
\tcode{realloc}
are restricted in this International Standard.
\ref{c.malloc} describes the changes.
