On 2014-08-19 09:39, Gavin Lambert wrote:
On 19/08/2014 19:21, Roland Bock wrote:
On 2014-08-19 04:17, Gavin Lambert wrote:
Now, this contains an int64_t value. The address of this value is given to the backend in the method bind() when fetching each result row (no laziness here). It seems to me that I cannot replace int64_t by boost::optional
. For instance, I cannot call get() to obtain the address of the value if the optional is not initialized (I would run into an assert). [...] Therefore it should be the backend's responsibility to fill in the On 19/08/2014 09:55, Roland Bock wrote: optional correctly If I had an optional in the result field, yes. -- ie. you should be passing an address/reference to the entire optional, not the internal integer. Some backends have functions like this (simplified):
void get_int_field(int index, int* retval);
How would I interact with such an interface if I had an optional<int>?
I think we've had a terminology clash. By "backend" I thought you meant "the sqlpp11 class that knows how to talk to the native driver", not the native driver itself. Of course the native driver probably won't know how to drive an optional, nor should it be expected to.
There are several layers, I assume:
1. User code 2. sqlpp11 database-independent frontend 3. sqlpp11 database-specific connector 4. native database library
BTW: I have proposed an open content session for CppCon to start writing a few more instances of Layer3. Apart from making the library usable for more people, this would also help to evaluate the pros and cons of the interface between 2&3. Cheers, Roland