Boost logo

Boost :

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-21 11:32:48

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

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at