In other words, for `optional<>`, the following assertion does not hold:
assert((opt == false) == (!opt));
[endsect]
[section Moved-from `optional`]
When an optional object that contains a value is moved from (is a source of move constructor or assignment) it still contains a value and its contained value is left in a moved-from state. This can be illustrated with the following example.
Quite a lot of people expect that when an object that contains a value is moved from, its contained value should be destroyed. This is not so, for performance reasons. Current semantics allow the implementation of `boost::opiotnal<T>` to be trivially copyable when `T` is trivial.
[endsect]
[section Mixed relational comparisons]
Because `T` is convertible to `optional<T>` and because `opiotnal<T>` is __SGI_LESS_THAN_COMPARABLE__ when `T` is __SGI_LESS_THAN_COMPARABLE__,
you can sometimes get an unexpected runtime result where you would rather expect a compiler error:
optional<double> Flight_plan::weight(); // sometimes no weight can be returned
} // returns false when the optional contains no value
[endsect]
[section False positive with -Wmaybe-uninitialized]
Sometimes on GCC compilers below version 5.1 you may get an -Wmaybe-uninitialized warning when copiling with option -02 on a perfectly valid `boost::optional` usage. For instance in this program:
#include <boost/optional.hpp>
boost::optional<int> getitem();
int main(int argc, const char *[])
{
boost::optional<int> a = getitem();
boost::optional<int> b;
if (argc > 0)
b = argc;
if (a != b)
return 1;
return 0;
}
This is a bug in the compiler. As a workaround (provided in [@http://stackoverflow.com/questions/21755206/how-to-get-around-gcc-void-b-4-may-be-used-uninitialized-in-this-funct this Stack Overflow question]) use the following way of initializing an optional containing no value: