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