We only support Clangs that implement nullptr as an extension in C++03 mode,
and we don't support GCC in C++03 mode. Hence, we can technically drop our emulation forthis patch disables the
use of the std::nullptr_tt emulation in C++03 modede by default. Doing that
is technically an ABI break since it changes the mangling for std::nullptr_t.
(1) The only affected users are those compiling in C++03 mode that have
std::nullptr_t as part of their ABI, which should be reasonably rare.
(2) Those users already have a lingering problem in that their code will
be incompatible in C++03 and C++11 modes because of that very ABI break.
Hence, the only users that could really be inconvenienced about this
change is those that planned on compiling in C++03 mode forever - for
other users, we're just breaking them now instead of letting them break
themselves later on when they try to upgrade to C++11.
(3) The ABI break will cause a linker error since the mangling changed,
and will not result in an obscure runtime error.
Concretely,Furthermore, if anyone is broken by this, they can define the
_LIBCPP_ABI_USE_CXX03_NULLPTR_EMULATION macro to return to the
previous behavior. the motivation for making this change is to make our own ABI consistent in C++03 and C++11 modes and to remove complexity around the definition of nullptrWe will then remove that macro after shipping
this for one release if we haven't seen widespread issues.
Concretely, the motivation for making this change is to make our own ABI
consistent in C++03 and C++11 modes and to remove complexity around the
definition of nullptr.
Furthermore, we could investigate making nullptr a keyword in C++03 mode
as a Clang extension -- I don't think that would break anyone, since
libc++ already defines nullptr as a macro to something else. Only users
that do not use libc++ and compile in C++03 mode could potentially be be
broken by that.