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