\infannex{diff}{Compatibility}

\rSec1[diff.iso]{\Cpp and ISO C}

\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}.

These keywords were added in order to implement the new

semantics of \Cpp.

Change to semantics of well-defined feature.

Any ISO C programs that used any of these keywords as identifiers

are not valid \Cpp programs.

Syntactic transformation.

Converting one specific program is easy.

Converting a large collection

of related programs takes more work.

Common.

\ref{lex.ccon}

\change Type of character literal is changed from \tcode{int} to \tcode{char}

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.

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.

Simple.

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}.''

This avoids calling an inappropriate overloaded function,

which might expect to be able to modify its argument.

Change to semantics of well-defined feature.

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}

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}

This avoids having different initialization rules for

fundamental types and user-defined types.

Deletion of semantically well-defined feature.

Semantic transformation.

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.

Seldom.

\ref{basic.scope}

\change A \tcode{struct} is a scope in \Cpp, not in C

Class scope is crucial to \Cpp, and a struct is a class.

Change to semantics of well-defined feature.

Semantic transformation.

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

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.

Change to semantics of well-defined feature.

Semantic transformation

Seldom

\ref{basic.start}

\change Main cannot be called recursively and cannot have its address taken

The main function may require special actions.

Deletion of semantically well-defined feature

Trivial: create an intermediary function such as

\tcode{mymain(argc, argv)}.

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.

Stricter type checking is essential for \Cpp.

Deletion of semantically well-defined feature.

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.

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.

\Cpp tries harder than C to enforce compile-time type safety.

Deletion of semantically well-defined feature.

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}

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

The type-safe nature of \Cpp.

Deletion of semantically well-defined feature.

Note: the original feature was labeled as ``obsolescent'' in ISO C.

Syntactic transformation.

Facilities for producing explicit function declarations are fairly

widespread commercially.

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 .

This prohibition helps to clarify the location of

declarations in the source code.

Deletion of a semantically well-defined feature.

Syntactic transformation.

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

\Cpp is an object-oriented language, placing relatively

more emphasis on lvalues. For example, functions may

return lvalues.

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.

Programs must add explicit casts to the appropriate rvalue.

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)

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.

Deletion of semantically well-defined feature.

Semantic transformation.

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

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.

Deletion of semantically well-defined feature.

Semantic transformation.

Add an appropriate return value to the source code, such as zero.

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}

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.

Deletion of semantically well-defined feature.

Syntactic transformation.

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}

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}

Deletion of semantically well-defined feature.

Semantic transformation.

One of the 2 types has to be renamed.

Seldom.

\ref{dcl.type} [see also \ref{basic.link}]

\change const objects must be initialized in \Cpp but can be left uninitialized in C

A const object cannot be assigned to so it must be initialized

to hold a useful value.

Deletion of semantically well-defined feature.

Semantic transformation.

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}

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.

Deletion of semantically well-defined feature.

Syntactic transformation.

Could be automated.

Common.

\ref{dcl.spec.auto}

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}

The type-safe nature of \Cpp.

Deletion of semantically well-defined feature.

Syntactic transformation.

(The type error produced by the assignment can be automatically

corrected by applying an explicit cast.)

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}

In \Cpp, an enumeration is a distinct type.

Change to semantics of well-defined feature.

Semantic transformation.

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}

This is to avoid erroneous function calls (i.e., function calls

with the wrong number or type of arguments).

Change to semantics of well-defined feature.

This feature was marked as ``obsolescent'' in C.

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.

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}

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.

Deletion of semantically well-defined feature.

Semantic transformation.

The type definitions must be moved to file scope, or in header files.

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.''

Prototypes are essential to type safety.

Deletion of semantically well-defined feature.

Syntactic transformation.

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}

When these non-terminated arrays are manipulated by standard

string routines, there is potential for major catastrophe.

Deletion of semantically well-defined feature.

Semantic transformation.

The arrays must be declared one element bigger to contain the

string terminating \tcode{'\textbackslash 0'}.

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}

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.

Change to semantics of well-defined feature.

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.

Seldom.

\ref{class.bit}

\indextext{bit-field!implementation-defined sign~of}%

Bit-fields of type plain \tcode{int} are signed.

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.

The choise is implementation-defined in C, but not so in C++.

Syntactic transformation.

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}

\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.

Change of semantics of well-defined feature.

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}.

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}

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.

Deletion of semantically well-defined feature.

Semantic transformation.

Either the type or the struct member has to be renamed.

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}

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.

Deletion of semantically well-defined feature.

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.

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

\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.

Change to semantics of well-defined feature.

Semantic transformation.

Programs and headers that reference \mname{STDC} are

quite common.

\rSec1[diff.cpp03]{\Cpp and ISO \CppIII}

\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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The following \Cpp headers are new:

\tcode{<array>},

\tcode{<atomic>},