On 2014-08-21 12:32, Bjorn Reese wrote:
On 08/19/2014 02:49 PM, Roland Bock wrote:
If I understand you correctly, you should be more happy with the current implementation then: As of today, depending on the compile-time configuration in the connector you have the following possible behaviors:
You can always check for NULL by calling is_null. But if you ignore the outcome and try to obtain the value of a field which happens to be NULL
Variant A: an exception is thrown Variant B: the "trivial" value is returned, 0 for numbers.
The Variant is chosen at compile time.
I find it a bit worrying that this behavior is changeable at compile-time, as it makes reviewing and reuse more challenging.
With optional<T> you will get variant A.
That is not the case, is it? * If I call get_value() on a NULL field in variant A, an exception gets thrown. * If I call get() on an uninitialized boost::optional, I run into a BOOST_ASSERT. By default, this is equivalent to C-assert (ie not an exception), but you can also turn it off completely at compile time. Then, you will have basically undefined behavior. Or you can configure BOOST_ASSERT at compile time to do something entirely different. I fail to see how the optional-way would any better with respect to compile-time configuration and code re-use or code reviews. When get() is used, you have no idea what will happen tomorrow. You only know for sure when get_value_or() is used. That's why I prefer Variant B anyway: No matter what, at least you get a defined value in case you run into a NULL. And if you really need to know that something is NULL, you have to check that regardless of whether it is an optional or not. Best, Roland