Boost logo

Boost :

Subject: Re: [boost] [variant2] Formal review
From: Peter Dimov (pdimov_at_[hidden])
Date: 2019-04-17 14:26:06


Andrzej Krzemienski wrote:

> However, you seem to be missing the distinction which I find very
> important: a "zombie" state that can only occur in *very special
> situations* (which correspond to the incorrect programs) is something
> substantially different than "zombie" states that can occur everywhere.

In a correct program using two-phase init, zombie states also cannot occur.
The same rule is in effect: a correct program should never access a
partially constructed object. There's nothing that makes the situation of a
partially constructed object being observed any less special or *very
special* than in what you suggest.

The problem is not one to be solved by putting asterisks around words. The
problem, as I said, is that the rules governing correct programs are hard to
enforce, and their violation is detected much too late, in parts of the
program that have done nothing to violate the rules.

With your rules, when the following very special situation throws:

    x1 = std::move(x2);

you now have x1 singular, because no basic exception safety, and x2
singular, because moved-from. Now whether the program is correct or not
depends on whether one of x1 or x2 escapes unscathed. This is hard to
diagnose statically - not that anyone has even tried - and will not be
diagnosed at runtime until two hours later an unrelated part of the program
tries to access x1 or x2, in which case you'll have a crash ("fast fail"),
except it won't be fast, and it will tell you nothing about what caused it
or who was at fault.

There's really not that much difference between the above and

    x1.init( f() );

except this one is easier to diagnose statically.

> Again, I am not convinced that you are seeing the distinction between
> "zombie states in very special circumstances" and "zombie states
> everywhere". I agree with you on "zombie states everywhere".

You're constructing a strawman of your choosing and setting it on fire.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk