Re: [boost] sqlpp11, 3rd iteration

Subject: Re: [boost] sqlpp11, 3rd iteration
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-19 03:05:12

On 2014-08-19 02:09, Adam Wulkiewicz wrote:
> Roland Bock wrote:
>> On 2014-08-18 22:43, Adam Wulkiewicz wrote:
>>> But AFAIU if the C++ objects were created along with the
>>> representation of a row, the results could be stored as optionals. Or
>>> am I missing something?
>> Yes the values are set when the row is fetched. The objects are re-used
>> for each row. And the backend is given pointers to write the value into
>> as explained above.
>>
>> But while writing this, I just realized: I could do is offer a
>> conversion operator for std::optional<int64_t>, of course. Thus, given a
>> row with a column `a` which can be NULL, you would then have
>>
>> std::optional<int64_t> a1 = row.a; // OK
>> int64_t a2 = row.a; // compile failure
>
> Is it the same way with bigger objects, e.g. std::strings?
Yes, but see below.
> Is the pointer to std::string passed to the backend (which means that
> some temporary buffer must be used) or must the pointer to the memory
> owned by std::string be passed, after resizeing a string?
Afaik, I must not pass the memory owned by a string to anybody for
modification, since writing to the return values of both
std::string::data() and std::string:c_str() results in undefined behavior.

Anyway, with text results, the situation is special since the memory is
actually owned by the backend. All the backends I've seen so far work
this way.

[...]

>
> Even temporary buffers could be ommited. Hmm, it probably even
> wouldn't be required to pass an optional to the backend. An optional
> could be created with default-constructed value:
>
> member = optional<int64_t>(int64_t());
>
> or re-constructed in case there were no valid value stored, probably
> like this:
>
> if ( !member )
>     member = optional<int64_t>(int64_t());
>
> and then the address of this value already stored within optional
> could be passed deeper:
>
> if ( backend.fill(member.get_ptr()) == false )
>     member = optional<int64_t>();// null
>
> Or am I missing something?
Sure that's possible, but what's the benefit over using a plain value
and a flag?
For each row to be fetched, I would have to check and potentially
reconstruct the optional value just to invalidate it again, if the value
is NULL in the new row.

In my eyes this just adds overhead for the internal representation.

> Btw, I'm not saying you should change the interface. I was just
> surprised that it couldn't be done.

Got that :-)

Regards,

Roland