On Thu, 20 Dec 2018 at 23:53, François Dumont <frs.dum...@gmail.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 are observable. > 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 > expect. 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 http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3050.html and also http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2855.html
