Hello, On 11/10/2024 21:43, Jonathan Wakely wrote:
Or alternatively, and arguably simpler, we could get rid of the ugly
_GLIBCXX20_INIT macro and just do this:
+#if __cpp_lib_atomic_value_initialization
+ atomic() noexcept (is_nothrow_default_constructible_v<_Tp>)
+ requires (is_default_constructible_v<_Tp>)
+ : _M_i() { }
+#else
atomic() = default;
+#endif
~atomic() noexcept = default;
atomic(const atomic&) = delete;
atomic& operator=(const atomic&) = delete;
This is now basically my original patch :) but it does correctly not value-initialize _M_i in pre-C++20 modes -- my bad, I didn't realize that P0883R2 was *not* meant to be treated as a DR and backported.
This more closely matches what's in the standard, except that we have a requires-clause on the default constructor. It seems like a defect that the standard doesn't do this, instead requiring is_constructible<atomic<NDC>> to be true, but Mandating an error if you try to use it.
Did you mean is_default_constructible? Yes, the core of the "problem" seems to be the Mandates instead of the Constraints used to describe atomic()'s default constructor in https://eel.is/c++draft/atomics.types.operations#1 . I also think a constraint would be more natural, in line with the idea of atomic<T> "wrapping" a T object. I don't seem to find any rationale for this choice in P0883's revisions, I guess I'll just ask SG1 and/or possibly submit a LWG issue.
Thank you again for the review, -- Giuseppe D'Angelo
smime.p7s
Description: S/MIME Cryptographic Signature
