Nicola Musatti wrote:
I started out with the idea of writing a "Boostable" library so it came natural to leverage existing representations for useful abstractions.
Nicola, Could you elaborate what you consider as boostable or boostified intefrace/library? May be you could point a document where I can find general guidelines about Boost conforming library interface design? I noticed you're using these terms like "boostified version of SOCI" or "suitability of some of the interface choices" or "with Boost compliance in mind" but I have no idea how to understand them. Understanding of these terms may be crucial to identify if SOCI is or isn't compliant with Boost library interface design guidelines, etc. I believe, it's not only a matter of taste, is it?
Row r; sql << "select * from ex2", into(r);
// Columns may be accessed by position... std::cout << r[0].as<long>() << "\t ";
SOCI equivalent: r.get<long>(0)
I consider this a small abstraction mismatch: you apply the index to the row and then you convert the field value to a C++ type. By the way, in this case operator[] is the natural way to express indexing, so I believe that operator overloading should be preferred.
I agree, only and only if elements of a sequence can be identified only by index. In SOCI, when working with Row representation the situation is different - elements of Row can accessed *also* via name, what's natural in DBMS, where columns are named. So, SOCI interface is consistent and intuitive in this case: r.get<long>(0) r.get<long>("column1) See: http://soci.sourceforge.net/doc/reference.html#row
Or you can test explicitly: eIndicator ind = r.indicator(2); if (ind == eNUll) { //etc...}
This is good too, but it comes for free when you use Boost.Optional. [...]
OK, and that's a good proposal for further development. Cheers -- Mateusz Loskot http://mateusz.loskot.net