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

[Eric Fiselier via libcxx-dev]

I plan to disable GCC with C++03 later today if there are no objections.
(See https://reviews.llvm.org/D63154)

Afterwards, I'll start another thread about the direction we want to set
with Clang, our C++03 extensions in general, and the future for C++03.

/Eric



On Wed, Jun 12, 2019 at 12:51 PM Zoe Carver <z.zoelec2 at gmail.com> wrote:

> I know I am a bit late to this discussion, but for what it is worth I
> completely agree with what Eric has said here.
>
> A few things to add:
> 1. Removing support for G++03 will allow us to get rid of a lot of code.
> For example, we have 5 overloads for each shared_ptr creation function
> where one is all that is needed.
> 2. Each patch will be much easier and faster to write. When we do not need
> to take into account supporting many C++03 features, we will be able to
> write smaller patches that are less complex. Additionally, fewer patches
> will need to be re-written.
> 3. As Eric pointed out in his original message, a lot of libc++ does not
> work with G++03. No matter what, I don't think it is a good idea to
> half-support something. It looks bad for libc++ to say it supports G++03
> and in reality only support it sometimes.
> 4. For those who still need to use G++03, they can get the old libc++ code
> that is still compatible. There is no reason someone cannot head over to
> the llvm download page and download libc++ 8.0. If they are still using
> G++03, they are probably OK without the latest and greatest.
>
> On Mon, 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.
>>
>>
>> * 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/20190612/e0dc279d/attachment-0001.html>