Re: [boost] Formal review: Optional library

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-11 10:50:27

Fernando Cacciola said:
> From: "William E. Kempf" <wekempf_at_[hidden]>
>> Fernando Cacciola said:
>> > Eventually, I realized that value semantics are not really
>> appropiate to deal
>> > with unininitialized states since it blurs the distinction between
>> testing against other values and testing whether it is initialized
>> or not. So I wonder which other semantics would deal with it
>> properly, and pointers poped into my mind quickly.
>>
>> But pointers are just the inverse of the problem above.  Test for
>> validity is bald.
>
> Only if safe_bool isn't used.

Huh?  safe_bool with a pointer?

> But, I'm just about to be convinced to added it, in which case,
> test for validity will look just like it looks like
> for any other smart/bare pointer.
>
>>, while access to the "value" requires some supporting syntax (in
>> this case, operator*).  This leaves users in the exact same scenario
>> where a simple mistake leads to code that compiles but doesn't do what
>> the programmer meant.
>
> Can you give me an example of something that compiles but
> doesn't do what the programmer meant?
> Remeber that currently *opt=x is defined even if opt is uninitialized

bool* p = &some_bool;
if (p) // meant if (*p)

Mistakes similar to this have been made by most C++ programmers.

>> I still don't see the need for the proxy.  The interface I gave could
>> provide "deep-constantness" with out a proxy.  I'm not sure where I
>> stand on whether or not optional<> should provide this, however.
>>
> Right. I mistakenly forgot what the proxy is for...
> it has nothing to do with deep-constantness... o-)
> it is required to support *opt=x for uninitialized optionals, which
> reset 'opt'
> to initilized.

Which according to the documentation would result in undefined behavior ;).

William E. Kempf