[libcxx-dev] Advancing libc++ Beyond C++03
Zoe Carver via libcxx-dev
libcxx-dev at lists.llvm.org
Wed Jun 12 09:51:38 PDT 2019
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:
> 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.
> * 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