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

Mon Jun 10 18:57:50 PDT 2019

On Mon, Jun 10, 2019 at 9:42 PM James Y Knight <jyknight at google.com> wrote:

> 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.
>

It's not quite that simple. libc++ was explicitly designed to target C++11
and later. It has no notion of C++03.

Internally the library depends on buckets of C++11 library features to
implement C++03 components. <type_traits>, <atomic>, unique_ptr, the C++11
allocator model, etc...
Trying to separate out C++03 would be impossible, and subdividing the
library harmful.

The good news is that removing the C++03 fallbacks is the fix. We're just
going to use the C++11 implementations.

/Eric

PS. The biggest issue I've had is separating `>>`.

> 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/2c2baf16/attachment.html>