Re: [boost] [variant2] Andrzej's review -- design

Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-03 08:09:16

wt., 2 kwi 2019 o 22:59 Peter Dimov via Boost <boost_at_[hidden]>
napisał(a):

> 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;