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

[Eric Fiselier via libcxx-dev]

Most users have a new Clang compiler, but still specify C++03. Old
compilers aren't the problem,
and our tolerance for C++03 must match Clang. Thankfully Clang provides
much of C++11 as an extension;
including _Atomic.. GCC is  much stricter and problematic. Currently 75% of
libc++'s C++03 tests fail with GCC.

The greatest benefactor of the Clang and libc++'s C++11 extensions is
libc++. We use `unique_ptr` to write
exception safe code in `vector` and `map`. We *require* C++11 reference
collapsing, and we exploit `decltype`,
 `nullptr`, and variadic templates being available as extensions. All to
avoid C++03 shortcomings.

We should plan for the day we drop C++03 support entirely. We shouldn't
create a conforming C++03 mode
15 years later.

How much of the initial problem is mitigated if you assume the host
compiler is a modern Clang?

/Eric

On Mon, Feb 11, 2019 at 3:48 PM James Y Knight via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> 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> 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> 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> on behalf of
>> Olivier Giroux via libcxx-dev <libcxx-dev at lists.llvm.org>
>> *Reply-To: *Olivier Giroux <OGiroux at nvidia.com>
>> *Date: *Tuesday, February 5, 2019 at 9:33 PM
>> *To: *"libcxx-dev at lists.llvm.org" <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
>> 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
>>
> _______________________________________________
> 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/20190212/2ad5dc19/attachment.html>