This is the mail archive of the
mailing list for the GCC project.
Re: Relax std::move_if_noexcept for std::pair
On Thu, 20 Dec 2018 at 23:53, François Dumont <email@example.com> wrote:
> >> 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.
> Indeed, I am not changing that.
Well, if you're not changing that, then I have no idea what is_const
is doing in your patch. :)
> > I don't understand what problem this is solving, and how it's not
> > introducing new problems.
> The problem I am trying to solve is shown by the tests I have adapted.
> Allow more move semantic in associative container where key are stored
> as const.
I'm not sure what you're trying to achieve is doable. The element of
an associative container is a pair,
and it has pair's semantics. It's also a pair<const Key, Value>, and
has those semantics. Those semantics
> But if I make counter_type copy constructor noexcept then I also get the
> move on the pair.second instance, great. I am just surprise to have to
> make a copy constructor noexcept to have std::move_if_noexcept work as I
Well, move construction/assignment via std::move or
std::move_if_noexcept is not necessarily
going to invoke just move constructors. Especially not for subobjects,
like pair's members.
> I think I just need to understand why we need std::move_if_noexcept in
> unordered containers or even rb_tree. Couldn't we just use std::move ? I
> don't understand what we are trying to avoid with this noexcept check.
We are trying to avoid data corruption on exceptions; if you move a
subobject and have to copy another,
and then that copy operation throws, you can't reliably move the
already-moved subobject back. See