[boost] Re: Re: Re: Optional, tie, and iterator_adaptor

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-01 15:29:34

Joel de Guzman <djowel_at_[hidden]> wrote in message
news:006b01c370b1$91aa1130$450caccb_at_godzilla...
> Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
> > Joel de Guzman <djowel_at_[hidden]> wrote in message
>
>
> > Direct value accesing via implicit conversion: int i = opt
> > seems wrong because this is the operation that can lead to undefined
> > behaviour.
>
> Doesn't have to be undefined behaviour.
>
Yes it does.
Accesing a value that isn't there is by all means undefined behaviour.

>  Aren't you throwing an
> exception or something?
>
This doesn't define the "access value" operation.
It just defines the function that is used to implement it.
But defining such a call doesn't help much from the POV of the
operation.
i.e., you cannot get the value if it isn't there and an exception
here is no better at it than a core dump.

Therefore, the operation is flaged as possibly undefined.
Whether to detect and throw, or assert, or do nothing is QoI issue.
If optional<> were to be someday standarized, implementators
would decide how to deal with the undefined behaviour here.

>variant throws throws a bad_get exception
> when you get a reference to a T which is not the held type. I don't see
> a problem why you can't do something similar.
>
Doing something similar as an implementation detail is fine.
Currently, I use BOOST_ASSERT, which allows the end user
to control how to deal with it.

Doing it as part of the interface, that is, contracting that
accesing an uninitialized optional throws an exception
has performance and portability problems.

In most typical usages, you don't really need a runtime check to get
always in the way of getting the value.
In fact, the pointer like syntax is there precisely to help
you be confident that an explicit check is not needed
since the access syntax lends itself to well written code
were uninitialized access is properly guarded in the
client code, allowing you to leverage the speed of unguarded
access while giving you at the same time the idiomatic
power of a familiar syntax to access possibly uninitialized
values.

Fernando Cacciola