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 indicators.
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 reasonable representation. 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[0].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 http://soci.sourceforge.net/doc/rationale.html
I did read it. I know that your choices were thought out in full, but I still disagree about a few things :-) Cheers, Nicola Musatti