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

Tue Feb 12 08:48:36 PST 2019

> On Feb 12, 2019, at 01:14, Eric Fiselier via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> 
> 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.

I agree that C++11 extensions in the COMPILER are useful, but extensions in the LIBRARY are not. We could use our own internal __unique_ptr type instead, that wouldn't be a problem.

In fact, I think most of the time it's a disservice to libc++ because we can't provide good support for those C++11 extensions, and that's a source of confusion and bugs. Also, it sometimes happens that simply providing the extension makes us non-conforming, as is the case for std::string_view.

You already know that, but I'm really not a big fan of extensions.

> 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?

Even a modern Clang does not support lambdas in C++03 mode:

$ echo 'int main() { [](int x) { }; }' | clang++ -xc++ - -std=c++03

It therefore doesn't make our life easier in this specific case.

Louis

> 
> /Eric
> 
> On Mon, Feb 11, 2019 at 3:48 PM James Y Knight via libcxx-dev <libcxx-dev at lists.llvm.org <mailto: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 <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://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 <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/64a19b5c/attachment-0001.html>