Fernando Cacciola <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
