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

[Olivier Giroux via libcxx-dev]

Is there a special step to test with c++03? Because I could pass make check-cxx with lambdas in <atomic>.

Olivier

From: Eric Fiselier <eric at efcs.ca>
Date: Sunday, February 10, 2019 at 2:11 PM
To: Olivier Giroux <OGiroux at nvidia.com>
Cc: 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?

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.
<atomic> is one example, <thread>, <unordered_map> and `std::shared_ptr` are others.

All of these components should have tests that run in C++03 (Tests are disabled in C++03 using the comment // UNSUPPORTED: c++98, c++03).




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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190211/95600af3/attachment-0001.html>