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

Subject: Re: [boost] [variant2] Andrzej's review -- design
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-06 18:19:58

sob., 6 kwi 2019 o 18:10 Steven Watanabe via Boost <boost_at_[hidden]>
napisał(a):

> AMDG
>
> On 4/6/19 3:37 AM, Rainer Deyke via Boost wrote:
> > On 06.04.19 02:46, Emil Dotchevski via Boost wrote:
> >> I do not think that it is a bug to access an object that is in a valid
> >> state. In fact, the reason why the state is defined as valid is so
> >> that you
> >> can safely work with that object, even after a failure was reported.
> >
> > One thing that bothers me about this view is that it is inconsistent
> > with how the language treats uninitialized variables.  Every bit pattern
> > of a variable of type 'char' is a valid value.  However, reading from an
> > uninitialized variable of type 'char' is undefined behavior.  On a
> > physical level, a variable of type char will always have a valid value,
> > but on the conceptual level, it can also have a special "uninitialized"
> > state from which it is legal to assign a new value but not to read the
> > current value.
> >
> > I find that using this conceptual uninitialized state actually makes it
> > /easier/ to reason about the correctness of my code.  Any code that
> > depends on the value of an uninitialized variable for its behavior is
> > automatically incorrect.  Any code that reads an uninitialized variable,
> > even if the value read does not affect the observable behavior of the
> > code, is automatically incorrect.  Just declaring an uninitialized
> > variable is a red warning light that I need to be careful to assign a
> > value to that variable before reading from it.  So long as I follow
> > these rules, I never have to worry about my code unexpectedly breaking
> > due to an uninitialized variable having an unexpected value.
> >
> > To me, the "valid but unspecified" state of an object after an exception
> > is thrown from a function with the basic exception guarantee is
> > conceptually very similar to the state of an uninitialized variable.  If
> > I catch such an exception while the object is still in scope, that's a
> > red warning light that I need to either assign a new state to the object
> > or allow the object to go out of scope.  Anything else risks the same
> > sort of errors as are caused by reading from an uninitialized variable.
> >
>
> That's completely different.  The scope
> in which a variable is uninitialized should
> always be known statically.  Also, uninitialized
> variables are never really a good thing.  It's
> just that it's sometimes more convenient than
> initializing them properly at the point of definition,
> and we can get away with it for trivial types.
>

One clarification about this last sentence, though. If one can write one's
function so that the object is initialized to its desired value this is
definitely superior to starting with an object with an unspecified value.
But if we are in the situation where we need to know the object's address
before we can assign it the desired value (such as in reading data from the
stream) starting with unspecified value is superior to programmer setting
some value like 0 which is intended to be overwritten in the same scope. In
case of unspecified value static analyzers can help us detect bugs when we
have forgotten to overwrite value in some branch.

Regards,
&rzej;