Byrial Jensen wrote:
> Warren Young wrote:
>
>> Byrial Jensen wrote:
>>
>>> So my question is: Do MySQL++ have a limitation so it only works with
>>> one actice Connection object at a time,
>>
>>
>> If it does, it's considered a bug. Patches thoughtfully considered.
>
>
> Thanks to Warren Young and Earl Miles for the replies. I don't have a
> patch, but I do have a very much cut down program to demonstrate the
> problems.
>
> When I run the program below with the cur table from the database dump
> found at
> http://download.wikimedia.org/wikipedia/da/20050516_cur_table.sql.gz,
> I get an abort in check_len() which seems to indicate that data returned
> from ResUse::fetch_row() have been changed. I suspect that this may be
> due to a mysql++ bug. It may of course also be due to misunderstandings
> on my side. If so, please tell me what's wrong with the program.
>
> When run with valgrind, I get thousands of invalid read errors. All
> about reads inside blocks previously free'd by the
> ColData_Tmpl<mysqlpp::const_string> destructor. Like this one:
From looking this over, I think your problem might be string manipulation.
const char *text = row[1];
I'm not sure row[] is guaranteed to return a null terminated string.
Without a null terminator, strlen() is guaranteed to fail and fail
badly. I believe what you really want is this (slightly longer than it
has to be for clarity):
std::string tempString = row[1];
const char *test = tempString.c_str();
Really, what you likely want is to avoid char* where you can and use
std::string, which is a remarkably efficient string library, if somewhat
large. And mysql++ is using it all over the place, so you lose nothing
by using it, and gain a *great deal* of string safety by doing so.
