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?
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?
AFAIU the reason of a problem with optionals is a limitation of the
implementation.
Couldn't a reference to optional be passed to the backend and then the
optional filled with data? E.g. using some temporary buffer or whatever
method suitable to get the data. And then the optional re-created using
this data.
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