noexcept move-ops for std::unordered_map

[sadseeker]

Предлагаю на уровне стандарта закрепить требование noexcept move операций для std::unordered_map.

Код c реализацией вашей идеи, если есть

как минимум libstdc++ реализует noexcept move операции. Не вижу хороших объяснений почему MSVC STL не может сделать также (https://godbolt.org/z/37v6jK8bf)

Обсуждения этой проблемы:

• Default non-throw move ctor with std::unordered_map member is not move constructible microsoft/STL#165
• https://stackoverflow.com/questions/47604029/move-constructors-of-stl-containers-in-msvc-2017-are-not-marked-as-noexcept

[isnullxbh]

Вы, очевидно, имели ввиду conditionally noexcept?

[tomilov]

Поддерживаю. Пришлось обрабатывать специальным образом из-за ассиметрии этого свойства в libc++ и в libstdc++.

[isnullxbh]

@tomilov, был бы Вам признателен, если бы вслед за дизлайком последовало и объяснение, почему Вы его поставили :)

[tomilov]

@tomilov, был бы Вам признателен, если бы вслед за дизлайком последовало и объяснение, почему Вы его поставили :)

Неочевидно, почему условный? По какому условию. Шаблон параметризуется типами. От каких их свойств предполагается выводить условие? У других еонтейнеров noexcept всегда безусловный. Почему здесь нужно сохранять ассиметричность?
Масса вопросов. Неочевидно.

[isnullxbh]

@tomilov, условный - потому что move constructor и move assignment operator шаблона класса std::unordered_map зависят от noexcept-гарантий соответствующих член-функций член-данных этого класса. Т.е., нельзя просто написать:

unordered_map(unordered_map&&) noexcept { ... }

, потому что у нас есть/может быть:

• объект аллокатора
• объект хешера
• объект предиката

и потенциально каждый из этих объектов может иметь, например, конструктор перемещения, который может сгенерировать исключение.

Поэтому я и говорю - conditionally noexcept. В коде это бы выглядело так:

unordered_map(unordered_map&&)
    noexcept(is_nothrow_move_constructible_v<hasher>
          && is_nothrow_move_constructible_v<key_equal>
          && is_nothrow_move_constructible_v<allocator_type>);

[tomilov]

@isnullxbh, пусть зависят. Очевидно (вот тут уж точно), что никакие прочие инварианты, накладываемые стандартом, не будут нарушены, если ту реализацию std::unordered_map, у которой специальные функции std::unordered_map::operator = (unordered_map&&) и std::unordered_map::unordered_map(unordered_map&&) являются noexcept(false), под капотом переделать на pimpl ("std::unique_ptr<std::unordered_map>"), то обе эти специальные функции легко переделать на noexcept(true).
Тем более как минимум в одной из libc++ libstdc++ обе эти функции -- noexcept и в остальном прочие инварианты, накладывамые стандартом, соблюдаются.

Разве есть требование к тому, чтобы объекты аллокатора, хэшера и предиката были данным-членами класса контейнера? Сомневаюсь. Даже если так, то аллокатор должен быть nothrow_copy_constructible/assignable и при определённых условиях move_constructible/assignable и тоже при этом обязательно "does not throw exceptions". Лень смотреть, но у прочих перечисленных объектов эти требования ещё жёще должны быть скорей всего.

[isnullxbh]

@tomilov, т.к. libc++/libstd++ уже не первый раз упоминается в данном треде, я это прокомментирую: ни в libc++, ни в libstdc++ реализация move-коструктора (например) шаблона класса std::unordered_map не содержит noexcept спецификатор:

• https://github.com/gcc-mirror/gcc/blob/f36a26b24c524434b11908f0e56ff33dba517f6b/libstdc%2B%2B-v3/include/bits/unordered_map.h#L194
• https://github.com/llvm/llvm-project/blob/6a12b7c74b179fbd1b40466f57d94dd8ed53cf16/libcxx/include/unordered_map#L981

move-конструктор помечен как = default, а это значит, что noexcept-гарантии компилятор будет формировать на основании членов-данных, базовых классов и т.п.

В обеих реализациях используется Hashtable (std::unordered_map имеет член-данных указанного типа), и, по сути, noexcept-гарантии move-конструктора std::unordered_map определяются noexcept-гарантиями move-конструктора Hashtable.
А если Вы заглянете в этот самый Hashtable, то увидете то, о чем я писал выше - noexcept, в котором используется условие.

[isnullxbh]

@tomilov, теперь по тексту:

под капотом переделать на pimpl ("std::unique_ptrstd::unordered_map"), то обе эти специальные функции легко переделать на noexcept(true)

Нет, не легко - в случае с move assignment operator это Вам вообще никак не поможет. Из-за правил allocator propagation возможна ситуация, когда Вам придется пересоздать элементы исходного контейнера в целевом. И тут уже ни о каких exception-free гарантиях не может быть и речи.

Разве есть требование к тому, чтобы объекты аллокатора, хэшера и предиката были данным-членами класса контейнера?

Формально - нет. Но и обратное не запрещено. Более того, так или иначе, частью стейта (или, правильнее сказать, частью наблюдаемого состояния) они обязаны быть (посмотрите на API std::unordered_map - он позволяет получить и аллокатор, и хешер, и предикат).

Сомневаюсь
Лень смотреть
должны быть скорей всего

Ну, извините, но тут я умываю руки :)

Если подытожить: того, что я написал выше про allocator propagation должно быть достаточно. @apolukhin, что скажешь?