Is there a reason why Row::at() doesn't take constant unsigned ints?
same with the [] operator.

Respectfully,
Alan Alvarez.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

alan.alvarez (AT) us (DOT) army.mil wrote:
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?unsu...ie.nctu.edu.tw

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 (AT) etr-usa (DOT) com>
Date: Monday, March 20, 2006 3:28 pm
Subject: Re: Row::at() doesn't take const int?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

alan.alvarez (AT) us (DOT) army.mil escreveu:
cast from non-const to const. it will, however, do the opposite. So I thi=
nk it'd be better to take a constant since the value is not modified anyw=
ays, or so I think. I could be wrong, which is why I was asking.
to a non-const reference.
But if that operator is operator[](int) there is not problem: the
parameter, rvalue or lvalue, will be copied into the function in all case=
s.

Declaring a function like this:

void
f (const int);

makes no sense.

--=20
Pedro Lamar=E3o
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

alan.alvarez (AT) us (DOT) army.mil wrote:
Are you saying that this code won't compile:


#include <iostream>

void foo(int bar)
{
std::cout << bar << std::endl;
}

int main()
{
foo(42);
return 0;
}


? If so, please give platform and compiler details.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Though the below code compiles I'm getting the follwoig error from the compiler:

SqlManager.cpp:167: error: ambiguous overload for 'operator[]' in 'l_row[0]'
/usr/local/include/mysql++/row.h:114: note: candidates are: const mysqlpp::ColData mysqlpp::Row:perator[](const char*) const
/usr/local/include/mysql++/row.h:126: note: const mysqlpp::ColData mysqlpp::Row:perator[](unsigned int) const

Here's the code for line 167:
return l_row[0];

so I'm forced to do the following:
unsigned int l_tmp = 0;
return l_row[l_tmp];

and this compiles fine.

Respectfully,
Alan Alvarez.

----- Original Message -----
From: Warren Young <mysqlpp (AT) etr-usa (DOT) com>
Date: Monday, March 20, 2006 9:19 pm
Subject: Re: Row::at() doesn't take const int?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

hi list!
hihohuhhh!!!

you're passing 0. so the compiler has to decide: "hmm, passing a null-point=
er to const char* or a=20
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[] whic=
h could in turn call=20
operator[](unsigned int); how about this idea?

hmm, sorry to send this message a second time, but i used the wrong mail ad=
dress the first time .
=20
Am Montag 20 M=E4rz 2006 15:46 schrieb alan.alvarez (AT) us (DOT) army.mil:
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.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

alan.alvarez (AT) us (DOT) army.mil escreveu:

return l_row[ static_cast<unsigned>(0) ];

There is no resolution to this situation in ISO C++.
I think current practice would refactor the (char const*) overload to a
member function.

--=20
Pedro Lamar=E3o
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

alan.alvarez (AT) us (DOT) army.mil wrote:
That's an ancient problem with MySQL++ and it has nothing to do with
constness. It's because the two overloads for Row:perator[] are for
const char* and unsigned int. Neither is the same type as a literal 0,
so the compiler has to decide which to coerce the 0 to. The ambiguous
conversion error tells you that the compiler can't decide between the
overloads because 0 converts to either equally well.

You'll find that if you change your subscript to 1, the code compiles,
because 1 can't be cast to const char* like 0 can.

This problem is documented in the reference manual. (Row:perator[])
The immediate solution is to use at() instead, which doesn't have the
const char* overload.

In the future, I think we can fix it by changing the unsigned int
overloads to plain int, but that would break the ABI, so we can't do
that until v3.0. If you want v3.0 to come faster, submit patches for
items in the Wishlist!

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Johannes Schaub wrote:
I tried it, and couldn't get it to work. There seem to be additional
overloading problems down that path. If you can make it work, I'd love
to see a patch for this, since just adding some more overloads mean we
don't have to wait for v3.0 to fix this.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw