Boost logo

Boost :

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

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