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

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-09-01 20:18:49

Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:

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

Wrong!

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

Pardon me, but you are clearly mistaken! Are you saying that variant's
get<T>(v) leads to undefined behavior? NO! 

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net