|
Boost : |
From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-11-01 19:05:10
Arkadiy Vertleyb wrote:
>
> > [JA:]
> > Ok. We would probably need to provide a default operator< for tables. For
> > efficiency, this might first compare number of rows, and if equal
> > recursively compare rows and columns.
>
> Why? Do we really need to sort on tables?
There are some reasons why this would be nice.
First of all, for consisteny: If I can create tables of ints, strings,
etc. without specifying the second template parameter (the "sort order",
really the primary "key"), then it would seem I should be able to do this
also when I use a type like a table that the library itself defines.
This really boils down to this argument: The current table implementation
actually imposes some requirements on the column types rather than truely
accepting "any type" whatsoever. One of these requiremnts is that the key
columns (those that are sorted) must be comparable with the std::less
template function. It seems to me that if the library requires this, then
it makes sense for the library's own types to also support this
requirement. Why should I not be able to use a table as a key?
> How was your experience with the library otherwise?
Only did a few very limited trials. In addition to the nested relation
test, I played with some of the relational operators, like a projection of
a join with a renamed key column. This worked fine, except that there is
no escaping the ugly template syntax. Let's face it, in spite of its
power, the meta-programming capability, which C++ acquired almost by
accident, is a horrendously ugly programming language.
By the way, one important aspect of a rigorous relational model is that it
doesn't allow duplicates. The true relational projection operator
eliminates duplicates. To do this efficiently, in general, may require
materializing the result?
> Have you been able to build the tests? What compiler are you using?
Have not attempted to build the tests. I was playing with MSVC6 (because I
was at work, otherwise I'd have used gcc).
Joachim
-- work: joachima_at_[hidden] (http://www.netacquire.com) private: joachim_at_[hidden] (http://www.kraut.ca)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk