|
Boost : |
From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2006-10-05 08:44:09
On 10/5/06, Mateusz Loskot <mateusz_at_[hidden]> wrote:
> Phil Nash wrote:
> >>>> 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)
> >
> > What about:
> >
> > r[0].as<long>()
> > r["column1"].as<long>()
>
> It's a kind of syntactic sugar and IMHO does not make it more (or less)
> natural what Nicola is questioning.
Well, admittedly it's not quite "as the ints do", but it is consistent
with other languages and libraries (including MS's ADO), and is
"natural" in the index case.
I'm not personally too worried which of these is adopted anyway, was
just pointing out the obvious :-)
I'm more interested in how the iterator interface works out.
Regards,
[)o
IhIL..
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk