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

Mon Feb 11 12:47:03 PST 2019

> On Feb 11, 2019, at 11:38 AM, Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 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.

volatile was supported before C++11 🤡

More seriously: that’s an extremely compelling argument to justify not supporting <atomic> before C++11: there’s no way the compiler supports the required atomic builtins and doesn’t support C++11.

It would be odd for a codebase to purposefully be stuck in C++03 on a recent compiler, yet choose to use <atomic>: before C++11 people had their own implementation of atomic using inline assembly, so I expect <atomic> is the last thing to change in codebases upgrading to C++11 because whatever inline assembly they had before probably works fine and has oddly (and scarily) different semantics from <atomic>.

> 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 <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 <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
> 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/074a3abc/attachment-0001.html>