hi list!
hihohuhhh!!!
you're passing 0. so the compiler has to decide: "hmm, passing a null-pointer to const
char* or a
0 to unsigned int ??". perhaps this problem could be solved by creating an additional
operator[] which
takes just a "const int", so that the compiler chooses that operator[] which could in turn
call
operator[](unsigned int); how about this idea?
hmm, sorry to send this message a second time, but i used the wrong mail address the first
time :).
Am Montag 20 März 2006 15:46 schrieb alan.alvarez@stripped:
> Doing something like Row[1] will produce a compile-time error. Since 1 is created as
> a constant by the compiler. The compiler won't explicitely cast from non-const to const.
> it will, however, do the opposite. So I think it'd be better to take a constant since the
> value is not modified anyways, or so I think. I could be wrong, which is why I was
> asking.
>
> Respectfully,
> Alan Alvarez.
>
> ----- Original Message -----
> From: Warren Young <mysqlpp@stripped>
> Date: Monday, March 20, 2006 3:28 pm
> Subject: Re: Row::at() doesn't take const int?
>
> > alan.alvarez@stripped wrote:
> > > Is there a reason why Row::at() doesn't take constant unsigned ints?
> > > same with the [] operator.
> >
> > Since size_type is a typedef for unsigned int, I guess you're
> > complaining that it isn't const? What value could making it const
> > possibly provide? Constness only matters with reference and
> > pointer
> > parameters.
> >
> > --
> > MySQL++ Mailing List
> > For list archives: http://lists.mysql.com/plusplus
> > To unsubscribe:
> > http://lists.mysql.com/plusplus?unsub=1
>
