[libcxx-dev] Advancing libc++ Beyond C++03
Eric Fiselier via libcxx-dev
libcxx-dev at lists.llvm.org
Mon Jun 10 18:10:39 PDT 2019
Yes, fixing these ABI bugs would require an ABI change. I don't know of ABI
bugs in standard C++03 components,
I'm not sure how many users actually depend on our C++11 extensions in
C++03. Or how many of those people mix
different C++ dialects in the same binary.
My sense is that having a different ABI between C++11 and C++03 is worse
than breaking ABI compatibility once to fix that.
In the case of `std::function::operator()(...)`, the C++03 implementation
passes rvalues across the type-erasure boundary
by value, C++11 passes by rvalue reference. If both versions of the vtable
appear in your program than you've got problems.
It's less clear if deleting <__nullptr> emulation is as palatable for all
parties. I could imagine a user writing a declaration
that contains `std::nullptr_t` in the mangling.
On Mon, Jun 10, 2019 at 6:03 PM JF Bastien <jfbastien at apple.com> wrote:
> On Jun 10, 2019, at 1:37 PM, Eric Fiselier via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
> libc++ claims to support GCC with C++03 ("G++03"), and this is a problem
> for our users.
> Our C++03 users are all using Clang. They must be. Less than 9% of the
> C++03 tests pass with GCC . No non-trivial C++ program could work.
> Attempting to support G++03 impacts our QoI considerably. Unlike Clang,
> G++03 offers almost no C++11 extensions. If we could remove all the
> fallbacks for G++03, it would mean libc++ could::
> * Improve Correctness:
> Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists
> to admit for deviant semantics.
> * Achieve ABI stability between C++03 and C++11
> Differences between our C++03 and C++Rest branches contain ABI bugs. For
> example `std::nullptr_t` and `std::function::operator()(...)` are currently
> incompatible between C++11 and C++03, but could be fixed.
> Would we break ABI of C++03 using clang as a compiler? Would we only do so
> for STL features which aren’t actually part of C++03 anyways?
> * Decrease Compile Times and Memory Usage:
> Writing efficient SFINAE requires C++11. Using alias templates, libc++
> could reduce the number of instantiations it produces substantially.
> * Decrease Binary Size
> Similar to the last point, G++03 forces metaprogramming techniques that
> emit more debug information  . Compared to libstdc++, debug
> information size increases of +10% are not uncommon.
> I would like the communities blessing to officially unsupport GCC in C++03
> in the 9.0 release.
>  https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8
>  Clang and GCC are our only "supported" C++03 compilers. MSVC and XLC
> don't support C++03, we don't support ILC.
>  G++03 disallows default template parameters, so SFINAE must be written
> as default function parameters. Function parameters create live variables,
> live variables force debug info emission for their type, which emits debug
> information for the SFINAE construct.
>  Unlike C++03 metafunctions written with normal class templates, C++11
> alias templates aren't instantiated at every use.
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev