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

[Olivier Giroux via libcxx-dev]

It is not.

From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org> on behalf of Ben Craig via libcxx-dev <libcxx-dev at lists.llvm.org>
Reply-To: Ben Craig <ben.craig at ni.com>
Date: Monday, February 11, 2019 at 1:03 PM
To: James Y Knight <jyknight at google.com>, JF Bastien <jfbastien at apple.com>, "libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
Subject: Re: [libcxx-dev] What C++03 support should <atomic> have?

For <atomic>, I can imagine a world where a C++03 atomic is conservatively backed by the old __sync_* builtins.  I don’t recall if libc++ atomic is setup in such a way to be able to take advantage of the __sync_* builtins when the __atomic_* builtins and _Atomic keywords aren’t present.


From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via libcxx-dev
Sent: Monday, February 11, 2019 2:48 PM
To: JF Bastien <jfbastien at apple.com>
Cc: libcxx-dev at lists.llvm.org
Subject: [EXTERNAL] Re: [libcxx-dev] What C++03 support should <atomic> have?

IMO, Libc++ in C++03 is pretty weird in general -- it's odd that it tries to provide c++11 stdlib features in c++98/03 modes. That's certainly been the intended design from the beginning, but I'm not sure how useful it actually is or ever has been. I've personally found it both surprising and annoying, back when I actually used to care about pre-c++11 at all. :)

For example, a unique_ptr class is provided even pre-c++11. But, as soon as you try to do just about anything with it, it becomes clear that it doesn't (can't!) actually work as it should.

Or, std::promise and std::future are provided, but without move constructors, can you actually use it? Is there really even a point?

On Wed, Feb 6, 2019 at 2:21 PM JF Bastien via libcxx-dev <libcxx-dev at lists.llvm.org<mailto:libcxx-dev at lists.llvm.org>> wrote:
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=8MXCBvaFaYmqPvnvskMFFirEWeEho77oT9SGe-4z7Gg&s=du-qoc0GEQOP9j3X8iFS-EhWaeE_bbFSXxajUeiYiYY&e=>

_______________________________________________
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=8MXCBvaFaYmqPvnvskMFFirEWeEho77oT9SGe-4z7Gg&s=du-qoc0GEQOP9j3X8iFS-EhWaeE_bbFSXxajUeiYiYY&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190211/6e36304c/attachment-0001.html>