Re: [boost] sqlpp11, 3rd iteration

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
    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