[libcxx-dev] What C++03 support should <atomic> have?

Mon Feb 11 11:38:18 PST 2019

Playing Devil’s advocate, it’s possible there are potential users for a Freestanding library who are stuck on old compilers thanks to C++-hostile vendors. I’m willing to put the effort in for the greater good there.

But back to advocating against the Devil: the <atomic> header only works when specific builtins are provided, and those builtins are _not_ available on a compiler that has truly 0% support for C++11, because they appeared specifically to support <atomic>. Hence it only works in C++03 mode on a compiler that also has some kind of C++11 mode, so that’s a pretty narrow window of time that one has to be frozen into by the hostile vendor.

From: <ldionne at apple.com> on behalf of Louis Dionne <ldionne at apple.com>
Date: Monday, February 11, 2019 at 11:32 AM
To: Eric Fiselier <eric at efcs.ca>
Cc: Olivier Giroux <OGiroux at nvidia.com>, "libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
Subject: Re: [libcxx-dev] What C++03 support should <atomic> have?

On Feb 10, 2019, at 17:11, Eric Fiselier via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:

Libc++ is a C++11 STL implementation that tolerates C++03 compilers.
If a feature can be reasonably implemented in C++03, then we provide it.

It can be implemented in C++03, however there will be a visible code complexity cost in doing so with Olivier's patch (mostly because of the lack of lambdas).

<atomic> is one example, <thread>, <unordered_map> and `std::shared_ptr` are others.

Yes, but this was decided in a time where not many compilers supported C++11 properly, right? 8 years later, we have many compilers supporting C++11 properly.

I suspect the number of people that use a recent libc++ with a compiler that does not support C++11 is very, very close to 0. One would have to deliberately update libc++ while keeping the compiler old, and then point the compiler to the updated libc++ headers manually. Additionally, the number of people that are in that setup AND that want to use std::atomic is likely to be even smaller.

I have an impression that we might be making our lives harder just to provide something that nobody cares about. Is there a common use-case of libc++ I'm missing here? Maybe some Linux distribution doing something funky that makes the old-compiler-with-new-libc++ more widely used than I imagine?

Unless we have a reason to do otherwise, I'd vote for not caring about C++03 support in <atomic>.

Louis

On Wed, Feb 6, 2019 at 11:39 PM Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:
Maybe another way to test these waters is to ask what is actually being _tested_?

Olivier

From: <jfbastien at apple.com<mailto:jfbastien at apple.com>> on behalf of JF Bastien <jfbastien at apple.com<mailto:jfbastien at apple.com>>
Date: Wednesday, February 6, 2019 at 11:21 AM
To: Olivier Giroux <OGiroux at nvidia.com<mailto:OGiroux at nvidia.com>>
Cc: "libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>" <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>
Subject: Re: [libcxx-dev] What C++03 support should <atomic> have?

Doing atomics before 11 was pretty wild… So I understand that people using an old C++ want some nice atomics. At the same time… They really should update to C++11 or later.

What does libc++ try to do with new library features on old languages? Seems easy enough so support most of say optional or variant (without CTAD) before C++17. Is this done consistently? And how far back, do we even try to support C++98?

It seems like we can be nice where it’s easy, but at some point in time are we just supporting stuff nobody cares about?

On Feb 5, 2019, at 9:33 PM, Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:

Sorry, that quote is from my patch, but there’s identical code elsewhere in the file. I swear!

Olivier

From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org<mailto:libcxx-dev-bounces at lists.llvm.org>> on behalf of Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>
Reply-To: Olivier Giroux <OGiroux at nvidia.com<mailto:OGiroux at nvidia.com>>
Date: Tuesday, February 5, 2019 at 9:33 PM
To: "libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>" <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>>
Subject: [libcxx-dev] What C++03 support should <atomic> have?

There is a little bit of code in this file that suggests it once worked in C++03.

Like so:
#ifndef _LIBCPP_CXX03_LANG
    __cxx_atomic_type() _NOEXCEPT = default;
#else
    __cxx_atomic_type() _NOEXCEPT : __a_value() {}
#endif // _LIBCPP_CXX03_LANG

Is that an actual design goal? It looks like it’s broken right now.

Do we maintain this, or do we bump the assumed default to C++11?

Thanks for your guidance,

Olivier

________________________________
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
________________________________
_______________________________________________
libcxx-dev mailing list
libcxx-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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/20190211/c97c0b20/attachment-0001.html>