C++17 adds std::uninitialized_move
, but there is no std::uninitialized_move_if_noexcept
that would use std::move_if_noexcept
internally. In my opinion, it would be useful, since now, if we want to reallocate, we still need to write something 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(...);
Are there any particular reasons why std::uninitialized_move_if_noexcept
was not introduced in C++17?
A paper on "Extending memory management tools" at open-std.org has a section on uninitialized_move
which deals with this matter.
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_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 amove_if_noexcept
iterator. Given that there is currently no range-basedmove_if_noexcept
algorithm, such a solution is not considered here. It seems clear that such a feature is readily possible, however.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With