Hello Warren e.a.
>>I used the Result because it has
>>the nice iterator, which ResUse does not have.
>
> I'm not sure what you're saying. Did you do this:
>
> Result r = q.use(...)
>
> ? If so, that't not legitimate. You can't force a 'use' query result
> to be random-access.
Sorry for being unclear. I was using Query::store(), which returns a
Result, because I liked the fact that Result has an iterator. However,
as this is a random-access iterator, it apparently slows down for each
row used (funnily enough, without increasing memory use, and O(n^2),
instead of O(n) which I would expect).
> > So, I'm writing one in stead,
> "One" what? Do you mean you're adding an iterator to ResUse? If so, be
I am creating an inputiterator, since semantics for a forwarditerator
state that you can 'start from the beginning', and get the same result.
Currently, I don't see how that behaviour can be implemented without
redoing the query, or storing the results. Also, the iterator I need
only needs inputiterator semantics.
> of the question. Be sure it doesn't conflict with Result's iterator,
> too, since it subclasses from ResUse.
I will, but thanx for the reminder.
> Here's a direct link:
Thank you.
Erwin
--
erwin@stripped
The human genome is about 3 gigabases long, which boils down to 750
megabytes. Depressingly enough, this is only 2.8 Mozilla browsers."
-- Jamie Zawinski
