[libcxx-dev] Advancing libc++ Beyond C++03

[Eric Fiselier via libcxx-dev]

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.

/Eric

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:
>
> Hello,
>
> 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 [1][2]. 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 [3] [4]. 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.
>
> /Eric
>
> [1] https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8
> [2] Clang and GCC are our only "supported" C++03 compilers. MSVC and XLC
> don't support C++03, we don't support ILC.
> [3] 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.
> [4] 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190610/032a631a/attachment.html>