Re: [patch] row::operator[] - template version

On Mon, Sep 19, 2005 at 01:51:38PM -0600, Warren Young wrote:
> A solution we shouldn't overlook is simply changing the SizeType 
> definition at the const_subscript_iterator level to 'int'.  Negative 
> subscripts don't make sense, but the range checking in vector::at() will 
> take care of this.  Then we don't need ugly overloads, and can avoid the 
> risks pps brought up.

I assumed the unsigned int was useful somewhere, but that would indeed be
a useful way to fix it.

One thing to be careful about is whether we need to match types with the
mysql C API.  Interestingly, our num_fields() member returns an int already,
where mysql_num_fields() returns unsigned int, so we aren't completely
consistent.

Going in the other direction is important too (calling mysql C API with
an int-converted-to-unsigned), but I hope the C API checks for that too.

The maximum number of columns, as reported here in the comments:
        http://dev.mysql.com/doc/mysql/en/table-size.html
is considerably less than an int size. (not that anyone *should* create
the max number of columns)

The max number of rows, however, is a spot we might run into problems.
size_type is used as the return value for result::size(), the number of
rows.  It already casts C's my_ulonglong return type to unsigned int.
Going to an int only makes it worse.

- Chris


-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx