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

[James Y Knight via libcxx-dev]

IMO, it is a mistake to be attempting to provide a c++11 standard library
without the c++11 language, and we'd be better off *removing* those types
that cannot be implemented in c++03 (and are thus currently implemented
incompatibly or incorrectly) from libcxx's c++03 mode, rather than fixing
them.

On Mon, Jun 10, 2019, 9:27 PM JF Bastien via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

>
>
> On Jun 10, 2019, at 6:10 PM, Eric Fiselier <eric at efcs.ca> wrote:
>
> 
> 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.
>
>
>
> Ok thanks, that answers one of my questions: the C++03 extensions would
> break ABI. Would your suggested change affect compliant C++03 ABI?
>
> Breaking extensions seems less bad... but it’s reminiscent of the
> std::experimental discussion: what expectations have we given developers
> when using extensions? If we break ABI on just extensions, can we diagnose
> the breakage? Or just drop the extension (maybe keep it behind a flag,
> deprecate, etc)?
>
> Sorry for asking so many questions! In general I agree that shedding
> burden is useful, but I want to understand the caveats (if any). Maybe that
> can inform future extensions too :)
>
>
> /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
>>
>>
>> _______________________________________________
> 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/05d7c39f/attachment.html>