From: Warren Young
Date: July 8 2005 9:57am
Subject: Re: Possible bug? subscript_iterator::operator->()
List-Archive: http://lists.mysql.com/plusplus/4625
Message-Id: <42CE4E0A.6080209@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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:

	ColDataRef cd;
	row.at_ref(&cd);

That initializes cd with just a reference to the field data, which you 
can then get at directly if you need no type conversions.