On Mon, Mar 4, 2019 at 7:46 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:
I agree that one can make a good argument for (a variation of) > double_buffer_variant, which prioritizes strong guarantee over sizeof. But that's only needed when your contained types don't have noexcept move. In this case, a not unreasonable course of action is to hold them > by unique_ptr in the variant instead.
Except I don't want to pay for the dynamic memory allocation.
Types that don't have noexcept move typically already allocate. Yes, it's an extra allocation, but going from 1 to 2 is not the same as going from 0 to 1.
You're thinking of modern code, or code you are permitted to change.
I'm thinking of code that I am not permitted to change, whose moves are not noexcept because somebody forgot to mark them, and it's now written into stone for the next five years.
I've heard that some standard libraries used to define such move constructors. This, by the way, is proof positive that noexcept is defective: the thing that specifies that something can't throw is, practically speaking, useless in checking if something may throw.