Chris Frey wrote:
> Which, if I read this right, is returning a pointer to a temporary Row object
> returned from Result::operator(size_type i).
Sorry I put this on the back burner so long.
I think you're right in your interpretation, and I don't see an easy way
to make the arrow operator work.
It also seems to me that the subscript operator has the same problem.
The real problem here is that none of these containers (Row, Result, and
Fields) really keeps its elements in memory, in a ready-to-use fashion.
We're always creating temporaries and returning them. To get the
illusion of array access, where these operators return references
instead of copies, I think we'd have to keep a temporary copy of the
last element accessed. That breaks if multiple threads try to access a
container at once.
I don't think we should have been promising random access in the first
place. That implies indexing into an array, or some other simple
operation. This is just syntactic heroin.
I think we should turn "subscript_iterator" into "bidir_iterator", by
removing the random-access features. The containers still offer
random-access semantics (e.g. through at() members), if someone wants that.
> I think this iterator mechanism is ripe for optimization based on Byrial's
> earlier idea, but will probably have to wait for 2.0.
I'm not sure. Too many classes use this iterator mechanism, besides Result.
I wonder if a special version of ColData (ColDataRef?) and special at()
variants wouldn't be a better idea:
That initializes cd with just a reference to the field data, which you
can then get at directly if you need no type conversions.