<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<head>

<style>
BODY, P, DIV, H1, H2, H3, H4, H5, H6, ADDRESS, OL, UL, LI, TITLE, TD, OPTION, SELECT {
 font-family: Verdana;
 
}

BODY, P, DIV, ADDRESS, OL, UL, LI, TITLE, TD, OPTION, SELECT {  
  font-size: 10.0pt;
  margin-top:0pt;  
  margin-bottom:0pt;  
} 

BODY, P {
  margin-left:0pt; 
  margin-right:0pt;
}

BODY {
  line-height: ;
  background: white;
  margin: 6px;
  padding: 0px;
}

h6 { font-size: 10pt }
h5 { font-size: 11pt }
h4 { font-size: 12pt }
h3 { font-size: 13pt }
h2 { font-size: 14pt }
h1 { font-size: 16pt }

blockquote {padding: 10px; border: 1px #DDDDDD dashed }

a img {border: 0}

</style>




</head>


<body revision="ddd5crnh_24cg8b6m:289">

Benjamin Kosnik <span class=lg style=FONT-WEIGHT:normal>&lt;bkoz@redhat.com&gt;<br>
Matt Austern &lt;austern@google.com&gt;<br>
</span>N2270=07-0130<br>
2007-04-26<br>
<br>
<h1>
  Incompatible changes in C++0x
</h1>
This document collects the various source-incompatible changes and deprecation
suggestions that have been made for C++0x, and notes potential ABI trouble
spots. It is certainly not an exhaustive list, but it documents the changes that
may or will break code. It includes both core and library changes.<br>
<br>
The committee has not yet made a formal decision to break the ABI, but most
committee members seem to believe that C++0x will force vendors to make
ABI-incompatible changes.<br>
<h2>
  Existing source- and ABI-breaking changes
</h2>
This section describes decisions we have already made for C++0x that may break
or change the meaning of valid C++03 source code.<br>
<h3>
  Right angle brackets
</h3>
The following code is valid in C++98/03 (because
"<span style="FONT-FAMILY:Courier New">&gt;&gt;</span>" is a right-shift
operator) but invalid in C++0x (because the
"<span style="FONT-FAMILY:Courier New">&gt;&gt;</span>" closes two templates:
<p>
</p>
<pre style=MARGIN-LEFT:40px>template&lt;typename T&gt; struct X { };<br>template&lt;int N&gt; struct Y { };<br>X&lt; Y&lt; 1 &gt;&gt; 2 &gt; &gt; x;<br></pre>
<h3>
  New keywords and identifiers<br>
</h3>
The consequences of introducing new keywords are believed to be well understood,
and while care has been taken in choosing these keywords to minimize impact on
existing code (by choosing rarely-used identifiers), some C++98 code will be
invalidated by their addition.<br>
<br style=COLOR:#ff0000>
<span style=COLOR:#000000>New keywords include:
<span style="FONT-FAMILY:Courier New">axiom</span>,
<span style="FONT-FAMILY:Courier New">char16_t</span>,
<span style="FONT-FAMILY:Courier New">char32_t</span>,
<span style="FONT-FAMILY:Courier New">constexpr</span>,
<span style="FONT-FAMILY:Courier New">concept</span>,
<span style="FONT-FAMILY:Courier New">concept_map</span>,
<span style="FONT-FAMILY:Courier New">decltype</span>,
<span style="FONT-FAMILY:Courier New">late_check</span>,
<span style="FONT-FAMILY:Courier New">requires</span>,
<span style="FONT-FAMILY:Courier New">static_assert</span>. Pending proposals
for garbage collection, lambda, and threads suggest additional keywords not yet
voted into the standard.<br>
<br>
New additions to namespace <span style="FONT-FAMILY:Courier New">std</span>
include the following, broken down by identifying proposal.<br>
<br>
</span>
<div style=MARGIN-LEFT:40px>
  <span style=COLOR:#000000>Rvalue-references:</span><br>
  <span style=COLOR:#000000>identity, forward, unique_ptr</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>Type Traits:</span><br>
  <span style=COLOR:#000000>integral_constant, true_type, false_type, is_void,
  is_integral, is_floating_point, is_array, is_pointer, is_reference,
  is_member_object_pointer, is_member_function_pointer, is_enum, is_union,
  is_class, is_function, is_arithmetic, is_fundamental, is_member_pointer,
  is_scalar, is_object, is_compound, is_const, is_volatile, remove_const,
  remove_volatile, remove_cv, add_const, add_volatile, add_cv, remove_reference,
  add_reference, remove_pointer, add_pointer, is_signed, is_unsigned, rank,
  extent, remove_extent, remove_all_extents, is_pod, is_empty, is_polymorphic,
  is_abstract, has_trivial_default_contructor, has_trivial_copy_constructor,
  has_trivial_assign, has_trivial_destructor, has_nothrow_default_constructor,
  has_nothrow_copy_constructor, has_nothrow_assign, has_virtual_destructor,
  is_same, is_base_of, is_convertible, alignment_of, aligned_storage, decay,
  enable_if, conditional</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>New Character types:</span><br>
  <span style=COLOR:#000000>u16string, u32string</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>Least crazy:</span><br>
  <span style=COLOR:#000000>next, prev, is_sorted_until, is_sorted,
  is_heap</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>Random:</span><br>
  <span style=COLOR:#000000>linear_congruential_engine, mersenne_twister_engine,
  subtract_with_carry_engine, discard_block_engine, independent_bits_engine,
  shuffle_order_engine, xor_combine_engine, minstd_rand0, minstd_rand, mt19937,
  ranlux24_base, ranlux48_bse, ranlux24, ranlux48, knuth_b, random_device,
  seed_seq, generate_cannonical, uniform_int_distribution,
  uniform_real_distribution, bernoulli_distribution, binomial_distribution,
  geometric_distribution, negative_binomial_distribution, poisson_distribution,
  exponential_distribution, gamma_distribution, weibull_distribution,
  extreme_value_distribution, normal_distribution, lognormal_distribution,
  chi_squared_distribution, cauchy_distribution, fisher_f_distribution,
  student_t_distribution, discrete_distribution,
  piecewise_constant_distribution, general_pdf_distribution</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>TR1 + edits:</span><br>
  <span style=COLOR:#000000>reference_wrapper, bad_weak_ptr, shared_ptr,
  static_pointer_cast, dynamic_pointer_cast, const_pointer_cast, get_deleter,
  weak_ptr, enable_shared_from_this, result_of, mem_fn, is_bind_expression,
  is_placeholder, bind, placeholders, bad_function_call, function, tuple,
  ignore, tuple_size, tuple_element, array, get, hash, unordered_set,
  unordered_multiset, unordered_map, unordered_multimap, regex_constants,
  regex_error, regex_traits, regex, wregex, sub_match, regex_match,
  regex_search, regex_replace, regex_iterator, regex_token_iterator</span><br>
  <span style=COLOR:#000000></span><br>
  <span style=COLOR:#000000>C99:</span><br>
  <span style=COLOR:#000000>isblank, fenv_t, fexcept_t, feclearexcept,
  fegetexceptflag, fesetexceptflag, fetestexcept, fegetround, fesetround,
  fegetenv, feholdexcept, fesetenv, feupdateenv, hexfloat, imaxdiv_t, imaxabs,
  div, strtoimx, strtoumax, wcstoimax, wcstoumax, atanhl, cbrt, cbrtf, cbrtl,
  copysign, copysignf, copysignl, erf, erff, erfl, erfc, erfcf, erfcl, exp2,
  exp2f, exp2l, expm1, expm1f, expmil, fdim, fdimf, fdiml, fma, fmaf, fmal,
  fmax, fmaxf, fmaxl, fmin, fminf, fminl, hypot, hypotf, hpotl, ilogb, ilogbf,
  ilogbl, lgamma, lgammaf, lgammal, llrint, llrintf, llrintl llround, llroundf,
  llroundl, logip, log1pf, log1pl, log2, log2f, log2l, logb, logbf, logbl,
  lrint, lrintf, lrintl, lround, lroundf, lroundl, nan, nanf, nanl, nearbyint,
  nearbyintf, nearbyintl, nextafter, nextafterf, nextafterl, nexttoward,
  nexttowardf, nexttowardl, remainder, remainderf, remainderl, remquo, remquof,
  remquol, rint, rintf, rintl, round, roundf, roundl, scalbln, scalblnf, salbln,
  scalbn, scalbnf, scalbnl, tgamma, tgammf, tgamml, trunc, truncf, truncl,
  signbit, fpclassify, isfinite, isinf, isnan, isnormal, isgreater,
  istreaterequal, isless, islessequal, islessgreater, isunordered, int_fast8_t,
  int_fast16_t, int_fast32_t, int_fast64_t, int_least8_t, int_least16_t,
  int_least32_t, int_least64_t, intmax_t, intptr_t, uint_fast8_t, uint_fast16_t,
  uint_fast32_t, uint_fast64_t, uint_least8_t, uint_least16_t, uint_least32_t,
  uint_least64_t, uintmax_t, uintptr_t, snprintf, vsnprintf, vfscanf, vscanf,
  vsscanf, lldiv_t, llabs, lldiv, atoll, strtoll, strtoull, strtof, strtold,
  div, wcstof, wcstold, wcstoll, wcstoull, vfwscanf, vswscanf,
  vwscanf</span><br>
  <span style=COLOR:#000000></span><br>
  Diagnostic Enhancements:<br>
  system_error, error_code, error_category, posix_category, native_category,
  hash_value, posix_errno,
  address_family_not_supported,<span style=FONT-FAMILY:monospace>
  </span>address_in_use,<span style=FONT-FAMILY:monospace>
  </span>address_not_available, already_connected, argument_list_too_long,
  argument_out_of_domain, bad_address, bad_file_descriptor,
  bad_message,<span style=FONT-FAMILY:monospace> </span>broken_pipe,
  connection_aborted, connection_already_in_progress, connection_refused,
  connection_reset, cross_device_link, destination_address_required,
  device_or_resource_busy,
  directory_not_empty,<span style=FONT-FAMILY:monospace>
  </span>executable_format_error, file_exists, file_too_large,
  filename_too_long, function_not_supported, host_unreachable,
  identifier_removed, illegal_byte_sequence, inappropriate_io_control_operation,
  interrupted, invalid_argument, invalid_seek, io_error, is_a_directory,
  message_size, network_down, network_reset, network_unreachable,
  no_buffer_space, no_child_process, no_link, no_lock_available,
  no_message_available, no_message, no_protocol_option, no_space_on_device,
  no_stream_resources, no_such_device_or_address, no_such_device,
  no_such_file_or_directory, no_such_process, not_a_directory, not_a_socket,
  not_a_stream, not_connected, not_enough_memory, not_supported,
  operation_canceled, operation_in_progress, operation_not_permitted,
  operation_not_supported, operation_would_block, other, permission_denied,
  protocol_error, protocol_not_supported, read_only_file_system,
  resource_deadlock_would_occur, resource_unavailable_try_again,
  result_out_of_range, stream_timeout, text_file_busy, timed_out,
  too_many_files_open_in_system, too_many_files_open, too_many_links,
  too_many_synbolic_link_levels, value_too_large, wrong_protocol_type<br>
</div>
<br>
New macros include all from the POSIX header &lt;errno.h&gt; plus EOTHER, from
&lt;fenv.h&gt;, &lt;cfloat&gt;, &lt;cinttypes&gt;, &lt;climits&gt;,
&lt;cmath&gt;, &lt;cstdarg&gt;, &lt;cstdbool&gt;, and &lt;cstdint&gt;<br>
<h3>
  Constant expressions
</h3>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2219.pdf title=N2219>N2219</a>
"Constant expressions in the Standard Library", changes the meaning of some
ill-behaved programs that use bitmask types in unintended ways. In C++03, for
example, <span style="FONT-FAMILY:Courier New">ios_base::fmtflags</span> is
defined to be an arbitrary bitmask type, as describe in 17.3.2.1.2.
Implementations are permitted to implement a bitmask type as an integer type, as
an enum, or as an <span style="FONT-FAMILY:Courier New">std::bitset</span>. On
an implementation that chooses to make
<span style="FONT-FAMILY:Courier New">ios_base::fmtflags</span> a
<span style="FONT-FAMILY:Courier New">bitset</span>, users could write
expressions like
<span style="FONT-FAMILY:Courier New">std::cout.flags().count()</span>, and on
an implementation that chooses to make<span style="FONT-FAMILY:Courier New">
ios_base::fmtflags</span> an integer, users could write expressions like
<span style="FONT-FAMILY:Courier New">std::cout.setf(17)</span>. Programs that
do these things were never portable, but they compile and run without error on
at least some platforms. N2219 requires ios_base::fmtflags to be an enum,
breaking both of these pathological examples.
<h3>
  Concepts
</h3>
Concepts have an unknown but potentially large impact on source compatibility,
largely because specifying the concepts in code is likely to prohibit some
pathological uses of standard library components that were never guaranteed to
work but that did happen to work on some implementations. Concept maps are
likely to affect mangling, and are thus likely to be a hot spot for ABI-breaking
changes. It is undetermined if the additional requirements for mangling can be
implemented so as to be compatible with existing ABIs for C++03.
<span style=COLOR:#ff0000></span><br>
<br>
Concepts also raise the question of container-like classes in the standard
library that do not meet the existing container requirements, such as
<span style="FONT-FAMILY:Courier New">std::bitset</span>,
<span style="FONT-FAMILY:Courier New">std::vector&lt;bool&gt;</span>,
<span style="FONT-FAMILY:Courier New">std::unordered_set</span>, and
<span style="FONT-FAMILY:Courier New">std::unordered_map</span>.<span style=COLOR:#ff0000></span>
In principle we could change those classes to come into conformance, or change
the requirements to include a minimal container concept that all containers
share, or deprecate or remove those classes. Any of those options can affect
source compatibility.<br>
<h2>
  Potential source- and ABI-breaking changes
</h2>
This section describes proposed changes, not yet approved for C++0x, that might
also break or change the meaning of valid C++03 source code.<br>
<h3>
  Container changes
</h3>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2217.pdf title=N2217>N2217</a>,
"Placement insert for containers," adds new insert overloads for containers. New
overloads can occasionally change which member function gets called. This is
probably not going to be an issue, however, because it is expected that the
revision of N2217 will give these member functions different names. As these are
non-virtual member function additions, it is believed to be ABI compatible.<br>
<br>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html title=N1771>N1771</a>,
"Impact of the rvalue reference on the Standard Library," adds&nbsp; new member
functions for containers: constructors with a std::size_t parameter,&nbsp; and
resize with a std::size_t and value type parameter. New constructors may impact
existing conversion sequences, but are believed to be ABI compatible.&nbsp;
<span style=FONT-WEIGHT:bold></span>
<h3>
  Allocator changes
</h3>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.pdf title=N2257>N2257</a>
proposes removing the allocator member functions
<span style="FONT-FAMILY:Courier New">construct</span>,
<span style="FONT-FAMILY:Courier New">destroy</span>, and
<span style="FONT-FAMILY:Courier New">address</span>, to make room for
<span style="FONT-FAMILY:Courier New">emplace</span> (as described in
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2217.pdf title=N2217>N2217</a>).
It calls for containers to use placement new, and explicit destructor calls,
instead. The proposal call for the removal of those member functions from both
std::allocator and from the allocator concept. This will break source
compatibility with C++03 code that calls those members directly, but is probably
not an ABI-breaking change. If users implement those members in their own
allocators and expect that the standard containers will call them, then this
change will make it impossible to do that. After a review of existing practice
in the GNU C++ library (libstdc++), (a) no such user code is known to exist
outside of tests cases, and (b) that code already isn't portable, since standard
containers aren't required to call those member functions.
<p>
</p>
<h3>
  Facets, locales, and iostreams
</h3>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2211.html title=N2211>N2211</a>
proposes enhancements to the time_get facet. It appears to be source-compatible
with C++03, but it may be ABI-breaking because it proposes new virtual member
functions.<br>
<br>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2186.html title=N2186>N2186</a>
proposes a number of small additions to iostream, including operator&lt;&lt; and
operator&gt;&gt; for <span style="FONT-FAMILY:Courier New">long long</span>,
access to the underlying file descriptor, and mutexes for iostream objects. All
of this appears to be source-compatible, but it is almost certainly ABI-breaking
and may be a change of behavior. Mutexes will change the sizes of objects, and
supporting <span style="FONT-FAMILY:Courier New">long long</span> will involve
adding new virtual member functions in I/O facets.<br>
<br>
In addition, a coherent strategy for dealing with error handling across the
standard library has yet to be devised. Known issues exist with current
iostreams error handling and threads: thread cancellation and exception handling
issues may be incompatible, as currently defined. As major new functionality
(like atomics and threads) get integrated into the C++ library, exiting error
handling strategies may have to adapt. These changes may make C++0x code catch
or throw errors differently than C++03.<br>
<br>
We have not yet decided on a policy for fixing other design mistakes in locale,
<span style=FONT-STYLE:italic>e.g.</span> the messages facet.<br>
<h2>
  Existing deprecated changes<br>
</h2>
The latest draft of C++0x has moved the following C++03 items to annex D,
deprecated.<br>
<br>
<ul>
  <li>
    <span style="FONT-FAMILY:Courier New"> std::bind1st</span>,
    <span style="FONT-FAMILY:Courier New">std::binder1st</span>,
    <span style="FONT-FAMILY:Courier New">std::bind2nd</span>,
    <span style="FONT-FAMILY:Courier New">std::binder2nd</span> (since
    <span style="FONT-FAMILY:Courier New">std::bind</span> does everything they
    do, but better)
  </li>
  <li>
    The use of an operand of type
    <span style="FONT-FAMILY:Courier New">bool</span> with the ++ operator
  </li>
  <li>
    The use of the <span style="FONT-FAMILY:Courier New">static</span> keyword
    when declaring objects in namespace scope.
  </li>
  <li>
    Access declarations.<br>
  </li>
</ul>
<h2>
  Potential deprecated changes
</h2>
<h3>
  vector&lt;bool&gt;
</h3>
<a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2204.html title=N2204>N2204</a>
suggests deprecating
<span style="FONT-FAMILY:Courier New">vector&lt;bool&gt;</span> and closing
problematic semantic loopholes. It isn't yet clear what it means to deprecate a
single specialization of a template, but a future revision of that paper may
clarify this important procedural question. Others have suggested removing the
specialization entirely, instead of just deprecating it; yet others suggest
keeping <span style="FONT-FAMILY:Courier New">vector&lt;bool&gt;</span> in the
library, documenting its behavior, and adding concept support.<br>
<h3>
  Tuple and pair consolidation<br>
</h3>
It would be very nice for <span style="FONT-FAMILY:Courier New">pair&lt;int,
int&gt;</span> to be a POD, or rather, in Beman's new terminology, for it to be
a trivial type. Currently it fails to be a trivial type because it has a
user-defined default constructor. One option would be to fix that, i.e. to use
the new <span style="FONT-FAMILY:Courier New">=default</span> language feature
to remove the user-defined constructor. This would change behavior in a few
minor cases because of default initialization. The change is small enough that
it is probably acceptable, and we would probably have used this feature from the
beginning if it had been available in C++98. It is slightly worrying, however,
that the change would not manifest itself until run time.<br>
<br>
We should almost certainly change
<span style="FONT-FAMILY:Courier New">std::tuple</span>'s default constructor to
use <span style="FONT-FAMILY:Courier New">=default</span>, meaning that
<span style="FONT-FAMILY:Courier New">tuple&lt;T<sub style=FONT-STYLE:italic>1</sub>,...,T<sub style=FONT-STYLE:italic>N</sub>&gt;</span>
will be trivial iff
<span style="FONT-FAMILY:Courier New">T<sub style=FONT-STYLE:italic>1</sub>,...,T<sub style=FONT-STYLE:italic>N</sub></span>
are all trivial. Since <span style="FONT-FAMILY:Courier New">tuple</span> isn't
part of C++03, we don't have to worry about compatibility.<br>
<br>
If we do make this change in <span style="FONT-FAMILY:Courier New">tuple</span>
but not in <span style="FONT-FAMILY:Courier New">pair</span>, we should consider
deprecating <span style="FONT-FAMILY:Courier New">pair</span>. There is very
little reason, other than history, for the library to contain both
<span style="FONT-FAMILY:Courier New">pair&lt;T,U&gt;</span> and
<span style="FONT-FAMILY:Courier New">tuple&lt;T,U&gt;</span>. If we do
deprecate <span style="FONT-FAMILY:Courier New">pair</span> then we should
change all interfaces in the library that use it, including the associative
containers, to use <span style="FONT-FAMILY:Courier New">tuple</span> instead.
This will be a source-incompatible change, but it need not be ABI-breaking.<br>
<h3>
  Others
</h3>
Various people have suggested deprecating the following features:<br>
<ul>
  <li>
    std::auto_ptr (See
    <a href=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html title=N1771>N1771</a>)
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::valarray</span> (On the grounds
    that people who do serious array work in C++ tend to use Blitz, MTL, or some
    other third-party library, and if
    <span style="FONT-FAMILY:Courier New">valarray</span> is deprecated concept
    support will not have to be retrofitted.)
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::raw_storage_iterator</span>,
    which, especially in light of exception safety, has outlived its usefulness.<br>
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::mem_fun</span>,
    <span style="FONT-FAMILY:Courier New">std::mem_fun_ref</span>, and their
    associated classes (Again, since std::mem_fn has all the same functionality
    but is more convenient and uniform).
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::ptr_fun</span> and its associated
    classes
  </li>
</ul>
<h3>
  Potential removal candidates<br>
</h3>
<ul>
  <li>
    The decay of narrow string literals to
    <span style="FONT-FAMILY:Courier New">char*</span> (as opposed to
    <span style="FONT-FAMILY:Courier New">const char*</span>) was deprecated in
    C++03. There hasn't yet been a paper proposing removal for C++0x, but the
    intention was always that it be removed in a future revision of the
    standard. If we remove it in C++0x then we will, obviously, be breaking any
    code that currently relies on it.
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::valarray</span>
  </li>
  <li>
    <span style="FONT-FAMILY:Courier New">std::vector&lt;bool&gt;</span>
  </li>
</ul>
<br>
There is no proposal to remove the deprecated iostream features from D.6 and
D.7.<br>
<br></body>
</html>