Mateusz Loskot <mateusz <at> loskot.net> writes:
Nicola Musatti wrote: [...] 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?
The most reasonable starting point is: http://boost.org/more/lib_guide.htm .
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?
In part. Coding and naming conventions, library organization and directory structure are objective issues which are documented in the page I linked above or elsewhere in the Boost web site and other details may be gathered from how existing Boost libraries are organized, especially the most recent ones. On the other hand defining what consititutes a suitable interface for a Boost or a standard library has to do with personal expectations and experience, and can only be subject to consensus among interested developers.
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)
I do not agree. The use of square brackets with non integer arguments is common when speaking of associative maps and is present in the standard library in std::map's interface. Moreover, I was pointing out another issue: when you have a row you first index it to get a field and then you translate its value to your destination. What I wrote as r[0].as<long>() could be expressed in a more SOCI-like syntax as r.field(0).get<long>() Cheers, Nicola Musatti