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

[James Y Knight via libcxx-dev]

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