为什么没有std::uninitialized_move_if_noexcept？
Why there is no std::uninitialized_move_if_noexcept?
C++17 添加了 std::uninitialized_move，但是没有 std::uninitialized_move_if_noexcept 在内部使用 std::move_if_noexcept。在我看来，它会很有用，因为现在，如果我们想重新分配，我们仍然需要写一些东西 as
if constexpr (!std::is_nothrow_move_constructible_v<value_type>
&& std::is_copy_constructible_v<value_type>)
std::uninitialized_copy(...);
else
std::uninitialized_move(...);
C++17 中没有引入 std::uninitialized_move_if_noexcept 有什么特别的原因吗？
"Extending memory management tools" at open-std.org 上的一篇论文在 uninitialized_move 上有一节处理这个问题。
Some concern is raised about exception handling with respect to uninitialized_move. If a move-constructor throws, the source object may have been irreparably damaged. As there is no solution to this problem, we implement the natural and expected semantics of destroying all fully constructed objects in the destination buffer and propagating the exception. This matches the behavior of uninitialized_copy as closely as possible.
An additional algorithm, uninitialized_move_if_noexcept, could be considered as a resolution to this concern. Such an algorithm was found already implemented in libstdc++ using a move_if_noexcept iterator. Given that there is currently no range-based move_if_noexcept algorithm, such a solution is not considered here. It seems clear that such a feature is readily possible, however.
C++17 添加了 std::uninitialized_move，但是没有 std::uninitialized_move_if_noexcept 在内部使用 std::move_if_noexcept。在我看来，它会很有用，因为现在，如果我们想重新分配，我们仍然需要写一些东西 as
if constexpr (!std::is_nothrow_move_constructible_v<value_type>
&& std::is_copy_constructible_v<value_type>)
std::uninitialized_copy(...);
else
std::uninitialized_move(...);
C++17 中没有引入 std::uninitialized_move_if_noexcept 有什么特别的原因吗？
"Extending memory management tools" at open-std.org 上的一篇论文在 uninitialized_move 上有一节处理这个问题。
Some concern is raised about exception handling with respect to
uninitialized_move. If a move-constructor throws, the source object may have been irreparably damaged. As there is no solution to this problem, we implement the natural and expected semantics of destroying all fully constructed objects in the destination buffer and propagating the exception. This matches the behavior ofuninitialized_copyas closely as possible. An additional algorithm,uninitialized_move_if_noexcept, could be considered as a resolution to this concern. Such an algorithm was found already implemented in libstdc++ using amove_if_noexceptiterator. Given that there is currently no range-basedmove_if_noexceptalgorithm, such a solution is not considered here. It seems clear that such a feature is readily possible, however.