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
, of course. Thus, given a row with a column `a` which can be NULL, you would then have std::optional
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()); or re-constructed in case there were no valid value stored, probably like this:
if ( !member ) member = optional
(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
();// 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