wt., 2 kwi 2019 o 22:59 Peter Dimov via Boost
Andrzej Krzemienski wrote:
Can you show a destructor like that, does a visitatoin on a variant, and that you wouldn't be ashamed to put in your program?
The destructor doesn't have to do visitation. It merely needs to call a function f1, which calls a function f2, which calls a function f3, which calls a function f4, which does visitation.
What we've been telling you from the start is that this forces you to partition your functions into two classes, one allowed to do visitation, the other not, then keep track of which is which, never calling the wrong class in a destructor, or from a catch clause.
And, of course, this has nothing to do with visitation, specifically. The exception safety guarantee is a global thing. Once you lose basic, you lose it everywhere, not just for visit.
I think I will take it to a separate thread in order not to obfuscate the review. One other remark I forgot to mention in the initial message is that the library upon assignment and emplacement prefers to first create a "temporary" object and then move from into the desired location. This works under the implicit assumption that the move constructor is cheaper that the said initialization. But I do not think it is the case in general. Moves are faster compared to other initialization only in the cases where the type is implemented as a handle to parts that are remote: allocated on heap, or stored somewhere in the kernel, and who often have weak invariants: in the moved from state they do not represent any resource. But other types like std::array<>, static_vector, even if they provide noexcept move are as expensive as making another copy. This is another price to be paid for the never-empty guarantee. There are also the cases where some type has move operations that can obviously never fail, but the author forgot to annotate them with noexcept (or noexcept was not available at the time when the type was designed). This last problem could be addressed if variant2 did not use std::is_nothrow_move_constructible directly, but a custom type trait that users would be able to specialize, in order to control the behavior of variant2. Regards, &rzej;