This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Relax std::move_if_noexcept for std::pair
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 20 Dec 2018 10:04:21 +0200
- Subject: Re: Relax std::move_if_noexcept for std::pair
- References: <366bf0a3-2daf-d5c5-7a09-f1260c9c405f@gmail.com>
On Thu, 20 Dec 2018 at 08:29, François Dumont <frs.dumont@gmail.com> wrote:
>
> Hi
>
> I eventually find out what was the problem with the
> std::move_if_noexcept within associative containers.
>
> The std::pair move default constructor might not move both first
> and second member. If any is not moveable it will just copy it. And then
..as it should..
> the noexcept qualification of the copy constructor will participate in
> the noexcept qualification of the std::pair move constructor. So
> std::move_if_noexcept can eventually decide to not use move because a
> _copy_ constructor not noexcept qualified.
..and again, as it should.
> This is why I am partially specializing __move_if_noexcept_cond. As
> there doesn't seem to exist any Standard meta function to find out if
> move will take place I resort using std::is_const as in this case for
> sure the compiler won't call the move constructor.
That seems wrong; just because a type is or is not const has nothing
to do whether
it's nothrow_move_constructible.
I don't understand what problem this is solving, and how it's not
introducing new problems.