C++ Logo

std-proposals

Advanced search

Re: [std-proposals] 回复: Potential defect in std::construct_at

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Sun, 8 Dec 2024 13:51:32 +0100
niedz., 8 gru 2024 o 12:04 F. v.S. via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hi!
>
> This is a known LWG issue which has been resolved: https://cplusplus.github.io/LWG/issue3870.
>
> If you use the latest libc++ (Clang 20 trunk), the latest libstdc++ (GCC 15 trunk), or MSVC STL since VS 2022 17.7, the casting-away-constness use of construct_at will be error.
>
> Thanks,
> F.v.S.
>

And `a.~T()` is still legal? Should here const cast be required too?

> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sébastien Bini via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Sunday, December 8, 2024 18:40
> To: Std-Proposals <std-proposals_at_[hidden]>
> Cc: Sébastien Bini <sebastien.bini_at_[hidden]>
> Subject: [std-proposals] Potential defect in std::construct_at
>
> Hello,
>
> I recently noticed something unexpected: it is possible to construct an object over constant storage with `std::construct_at`. At least it works in gcc 13.2.0 and clang 18.
> Note that this is not possible with placement new.
>
> I tried playing with the following code:
> template <class T>
> void swap_const_references(T const& a, T const& b)
> {
> T c{a};
> a.~T();
> std::construct_at(&a, b);
> b.~T();
> std::construct_at(&b, c);
> }
>
> And it compiles fine with both compilers. If I replace the std::construct_at with placement new, the code fails to compile (cannot convert 'const void*' to 'void*').
>
> This swap_const_references is definitely something we don't want to be able to write! At least not without relying on UB. I can even make it constexpr and it is still compiling >< (and working as designed...)
>
> I don't know who is in the wrong here, between the library implementers and the C++ standard. But here is a case where code with a non-constexpr placement new is actually safer than the shinny construct_at...
>
> Should we open a defect to fix std::construct_at so it does not accept constructing over constant storage?
>
> Best regards,
> Sébastien BINI
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2024-12-08 12:51:45