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.


Could you elaborate what you consider as boostable or boostified
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"
"suitability of some of the interface choices"
"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:



>> 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.


Mateusz Loskot

Boost list run by bdawes at, gregod at, cpdaniel at, john at