Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2006-10-05 07:49:19


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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk