Annex C (informative) Compatibility [diff]

Subclause [diff.cpp03] lists the differences between C++ and ISO C++ 2003 (ISO/IEC 14882:2003, Programming Languages — C++), in addition to those listed above, by the chapters of this document.

Change: New kinds of string-literals.

Rationale: Required for new features.

Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this revision of C++.

Specifically, macros named R, u8, u8R, u, uR, U, UR, or LR will not be expanded when adjacent to a string-literal but will be interpreted as part of the string-literal.

For example: #define u8 "abc" const char* s = u8"def"; // Previously "abcdef", now "def"

Change: User-defined literal string support.

Rationale: Required for new features.

Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this revision of C++.

For example: #define _x "there" "hello"_x // #1

Previously, #1 would have consisted of two separate preprocessing tokens and the macro _­x would have been expanded.

In this revision of C++, #1 consists of a single preprocessing token, so the macro is not expanded.

Change: New keywords.

Rationale: Required for new features.

Effect on original feature: Added to Table 5, the following identifiers are new keywords: alignas, alignof, char16_­t, char32_­t, constexpr, decltype, noexcept, nullptr, static_­assert, and thread_­local.

Valid C++ 2003 code using these identifiers is invalid in this revision of C++.

Change: Type of integer literals.

Rationale: C99 compatibility.

Effect on original feature: Certain integer literals larger than can be represented by long could change from an unsigned integer type to signed long long.

Change: Only literals are integer null pointer constants.

Rationale: Removing surprising interactions with templates and constant expressions.

Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this revision of C++.

For example: void f(void *); // #1 void f(...); // #2 template<int N> void g() { f(0*N); // calls #2; used to call #1 }

Change: Specify rounding for results of integer / and %.

Rationale: Increase portability, C99 compatibility.

Effect on original feature: Valid C++ 2003 code that uses integer division rounds the result toward 0 or toward negative infinity, whereas this revision of C++ always rounds the result toward 0.

Change: && is valid in a type-name.

Rationale: Required for new features.

Effect on original feature: Valid C++ 2003 code may fail to compile or produce different results in this revision of C++.

For example: bool b1 = new int && false; // previously false, now ill-formed struct S { operator int(); }; bool b2 = &S::operator int && false; // previously false, now ill-formed

Change: Remove auto as a storage class specifier.

Rationale: New feature.

Effect on original feature: Valid C++ 2003 code that uses the keyword auto as a storage class specifier may be invalid in this revision of C++.

In this revision of C++, auto indicates that the type of a variable is to be deduced from its initializer expression.

Change: Narrowing restrictions in aggregate initializers.

Rationale: Catches bugs.

Effect on original feature: Valid C++ 2003 code may fail to compile in this revision of C++.

For example, the following code is valid in C++ 2003 but invalid in this revision of C++ because double to int is a narrowing conversion: int x[] = { 2.0 };

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 on original feature: A valid C++ 2003 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.

Change: User-declared destructors have an implicit exception specification.

Rationale: Clarification of destructor requirements.

Effect on original feature: Valid C++ 2003 code may execute differently in this revision of C++.

In particular, destructors that throw exceptions will call std​::​terminate (without calling std​::​unexpected) if their exception specification is non-throwing.

Change: Remove export.

Rationale: No implementation consensus.

Effect on original feature: A valid C++ 2003 declaration containing export is ill-formed in this revision of C++.

Change: Remove whitespace requirement for nested closing template right angle brackets.

Rationale: Considered a persistent but minor annoyance.

Template aliases representing non-class types would exacerbate whitespace issues.

Effect on original feature: Change to semantics of well-defined expression.

A valid C++ 2003 expression containing a right angle bracket (“>”) followed immediately by another right angle bracket may now be treated as closing two templates.

For example, the following code is valid in C++ 2003 because “>>” is a right-shift operator, but invalid in this revision of C++ because “>>” closes two templates.

Change: Allow dependent calls of functions with internal linkage.

Rationale: Overly constrained, simplify overload resolution rules.

Effect on original feature: A valid C++ 2003 program could get a different result than in this revision of C++.

Affected: [library] – [thread]

Change: New reserved identifiers.

Rationale: Required by new features.

Effect on original feature: Valid C++ 2003 code that uses any identifiers added to the C++ standard library by later revisions of C++ may fail to compile or produce different results in this revision of C++.

A comprehensive list of identifiers used by the C++ standard library can be found in the Index of Library Names in this document.

Change: New headers.

Rationale: New functionality.

Effect on original feature: The following C++ headers are new: <array>, <atomic>, <chrono>, <codecvt>, <condition_­variable>, <forward_­list>, <future>, <initializer_­list>, <mutex>, <random>, <ratio>, <regex>, <scoped_­allocator>, <system_­error>, <thread>, <tuple>, <typeindex>, <type_­traits>, <unordered_­map>, and <unordered_­set>.

In addition the following C compatibility headers are new: <cfenv>, <cinttypes>, <cstdint>, and <cuchar>.

Valid C++ 2003 code that #includes headers with these names may be invalid in this revision of C++.

Effect on original feature: Function swap moved to a different header

Rationale: Remove dependency on <algorithm> for swap.

Effect on original feature: Valid C++ 2003 code that has been compiled expecting swap to be in <algorithm> may have to instead include <utility>.

Change: New reserved namespace.

Rationale: New functionality.

Effect on original feature: The global namespace posix is now reserved for standardization.

Valid C++ 2003 code that uses a top-level namespace posix may be invalid in this revision of C++.

Change: Additional restrictions on macro names.

Rationale: Avoid hard to diagnose or non-portable constructs.

Effect on original feature: Names of attribute identifiers may not be used as macro names.

Valid C++ 2003 code that defines override, final, carries_­dependency, or noreturn as macros is invalid in this revision of C++.

Change: operator new may throw exceptions other than std​::​bad_­alloc.

Rationale: Consistent application of noexcept.

Effect on original feature: Valid C++ 2003 code that assumes that global operator new only throws std​::​bad_­alloc may execute differently in this revision of C++.

Valid C++ 2003 code that replaces the global replaceable operator new is ill-formed in this revision of C++, because the exception specification of throw(std​::​bad_­alloc) was removed.

Change: Thread-local error numbers.

Rationale: Support for new thread facilities.

Effect on original feature: Valid but implementation-specific C++ 2003 code that relies on errno being the same across threads may change behavior in this revision of C++.

Change: Minimal support for garbage-collected regions.

Rationale: Required by new feature.

Effect on original feature: Valid C++ 2003 code, compiled without traceable pointer support, that interacts with newer C++ code using regions declared reachable may have different runtime behavior.

Change: Standard function object types no longer derived from std​::​unary_­function or std​::​binary_­function.

Rationale: Superseded by new feature; unary_­function and binary_­function are no longer defined.

Effect on original feature: Valid C++ 2003 code that depends on function object types being derived from unary_­function or binary_­function may fail to compile in this revision of C++.

Change: basic_­string requirements no longer allow reference-counted strings.

Rationale: Invalidation is subtly different with reference-counted strings.

This change regularizes behavior.

Effect on original feature: Valid C++ 2003 code may execute differently in this revision of C++.

Change: Loosen basic_­string invalidation rules.

Rationale: Allow small-string optimization.

Effect on original feature: Valid C++ 2003 code may execute differently in this revision of C++.

Some const member functions, such as data and c_­str, no longer invalidate iterators.

Change: Complexity of size() member functions now constant.

Rationale: Lack of specification of complexity of size() resulted in divergent implementations with inconsistent performance characteristics.

Effect on original feature: Some container implementations that conform to C++ 2003 may not conform to the specified size() requirements in this revision of C++.

Adjusting containers such as std​::​list to the stricter requirements may require incompatible changes.

Change: Requirements change: relaxation.

Rationale: Clarification.

Effect on original feature: Valid C++ 2003 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:

• (2.1)
  not all containers provide size(); use empty() instead of size() == 0;
• (2.2)
  not all containers are empty after construction (array);
• (2.3)
  not all containers have constant complexity for swap() (array).

Change: Requirements change: default constructible.

Rationale: Clarification of container requirements.

Effect on original feature: Valid C++ 2003 code that attempts to explicitly instantiate a container using a user-defined type with no default constructor may fail to compile.

Change: Signature changes: from void return types.

Rationale: Old signature threw away useful information that may be expensive to recalculate.

Effect on original feature: The following member functions have changed:

• (4.1)
  erase(iter) for set, multiset, map, multimap
• (4.2)
  erase(begin, end) for set, multiset, map, multimap
• (4.3)
  insert(pos, num, val) for vector, deque, list, forward_­list
• (4.4)
  insert(pos, beg, end) for vector, deque, list, forward_­list

Valid C++ 2003 code that relies on these functions returning void (e.g., code that creates a pointer to member function that points to one of these functions) will fail to compile with this revision of C++.

Change: Signature changes: from iterator to const_­iterator parameters.

Rationale: Overspecification.

Effect on original feature: The signatures of the following member functions changed from taking an iterator to taking a const_­iterator:

• (5.1)
  insert(iter, val) for vector, deque, list, set, multiset, map, multimap
• (5.2)
  insert(pos, beg, end) for vector, deque, list, forward_­list
• (5.3)
  erase(begin, end) for set, multiset, map, multimap
• (5.4)
  all forms of list​::​splice
• (5.5)
  all forms of list​::​merge

Valid C++ 2003 code that uses these functions may fail to compile with this revision of C++.

Change: Signature changes: resize.

Rationale: Performance, compatibility with move semantics.

Effect on original feature: For vector, deque, and list the fill value passed to resize is now passed by reference instead of by value, and an additional overload of resize has been added.

Valid C++ 2003 code that uses this function may fail to compile with this revision of C++.

Change: Result state of inputs after application of some algorithms.

Rationale: Required by new feature.

Effect on original feature: A valid C++ 2003 program may detect that an object with a valid but unspecified state has a different valid but unspecified state with this revision of C++.

For example, std​::​remove and std​::​remove_­if may leave the tail of the input sequence with a different set of values than previously.

Change: Specified representation of complex numbers.

Rationale: Compatibility with C99.

Effect on original feature: Valid C++ 2003 code that uses implementation-specific knowledge about the binary representation of the required template specializations of std​::​complex may not be compatible with this revision of C++.

Change: Specify use of explicit in existing boolean conversion functions.

Rationale: Clarify intentions, avoid workarounds.

Effect on original feature: Valid C++ 2003 code that relies on implicit boolean conversions will fail to compile with this revision of C++.

Such conversions occur in the following conditions:

• (1.1)
  passing a value to a function that takes an argument of type bool;
• (1.2)
  using operator== to compare to false or true;
• (1.3)
  returning a value from a function with a return type of bool;
• (1.4)
  initializing members of type bool via aggregate initialization;
• (1.5)
  initializing a const bool& which would bind to a temporary object.

Change: Change base class of std​::​ios_­base​::​failure.

Rationale: More detailed error messages.

Effect on original feature: std​::​ios_­base​::​failure is no longer derived directly from std​::​exception, but is now derived from std​::​system_­error, which in turn is derived from std​::​runtime_­error.

Valid C++ 2003 code that assumes that std​::​ios_­base​::​failure is derived directly from std​::​exception may execute differently in this revision of C++.

Change: Flag types in std​::​ios_­base are now bitmasks with values defined as constexpr static members.

Rationale: Required for new features.

Effect on original feature: Valid C++ 2003 code that relies on std​::​ios_­base flag types being represented as std​::​bitset or as an integer type may fail to compile with this revision of C++.

For example: #include <iostream> int main() { int flag = std::ios_base::hex; std::cout.setf(flag); // error: setf does not take argument of type int }