From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-10-06 07:09:55
Steve Hutton <shutton <at> featurecomplete.com> writes:
> 1. Considering the use of boost::optional - it's is indeed the very
> elegant way to deal with NULL values, but SOCI indicators can provide
> more information than this. The indicator is a general information
> about the piece of data, which in addition to be eOK or eNull, might
> be also eTruncated (when the string is read into the buffer that is too
> short). boost::optional cannot do this and therefore cannot be the only
> interface. It might be provided as an additional interface for the most
> typical case (nobody's using char buffers anyway), but it cannot replace
I believe this is an instance of the need of representing concepts both in the
SQL and in the C++ world. I see indicators as conceptually a part of the SQL
world, in that they are a way to access additional, detailed information about
the result of a query, beyond the retrieved value itself.
Once the value is converted to a C++ type it assumes a value in the domain of
that type... or not. In this case boost::optional or its moral equivalent is a
Side note: a while ago I wrote a Nullable<T> type that provided implicit
conversion to T and threw an exception if it held a null value. Personally I'd
prefer that kind of interface, but I think it's better to stick as much as
possible to what's available in the standard library or in Boost.
> 2. Considering the indexing of Row (function-like vs. operator) - the
> syntactic sugar is a matter of taste, but I have nothing against, say,
> r.get<int>() (this is easy to do). Things like 'as<T>' are not so
> convincing, especially when compared with the existing interfaces,
> like boost::tuple.
I suspect there's some misunderstanding. By writing '.as<T>' I didn't mean to
imply that retrieved field values should be converted to arbitrary types. I just
feel, and I'm convinced that it's the same for you, that whenever it is possible
it is better to write 'get<int>' than 'get_int'. I used 'as' to express value
retrieval because it is used in libraries I'm familiar with.
The only conversion that might be reasonable is towards string/wstring, in case
the underlying technology provides an efficient implementation (e.g. because it
retrieves values as strings and only converts them upon request).
> 3. For rationale on the interface choices (like operator overloading),
> please see
I did read it. I know that your choices were thought out in full, but I still
disagree about a few things :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk