Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
- Subject: Re: _GLIBCXX_DEBUG _GLIBCXX_DEBUG_PEDANTIC nuttiness causing debug build crashes...
- From: Graham Reitz <email@hidden>
- Date: Wed, 5 Dec 2007 16:36:14 -0600
Ok thanks folks. You are not going to get an argument from me. I
agree completely. Although, I expect an argument from the author(s)
of mysql++ .
It must be in the mysql++ code, since the code (a simple main
function) only makes call into it.
The code is below for those of you that are interested. I would be
interested in hearing your opinions.
The code:
int main (int argc, char * const argv[])
{
string database_name = "db_rev_4";
string ip_address = "X.X.X.X";
string username = "admin";
string password = "admin";
string client_id = "graham";
string client_pw = "reitz";
string error_msg;
cout << "Attempting to connect to the database...";
Connection m_connection(database_name.c_str(),
ip_address.c_str(),
username.c_str(),
password.c_str(),
3306,
false,
15);
Result client_id_result;
try
{
cout << "connected to the database\n";
Query client_id_query = m_connection.query();
client_id_query <<
"select client_id from clients where client_user_name ="
<< quote_only << client_id << " and client_password ="
<< quote_only << client_pw;
cout << "Query created: " << client_id_query.preview() << endl;
client_id_result = client_id_query.store();
if (client_id_result)
{
cout << "Result received = " << client_id_result.rows()
<< endl;
Row client_id_row;
Row::size_type i = 0;
client_id_row = client_id_result.at(i);
}
Row client_id_row;
// The "=" versus "==" syntax is more mysqlpp bs
if (client_id_row = client_id_result.at(0))
{
cout << client_id_row.at(0) << endl;
return client_id_row.at(0);
}
}
catch (exception &e)
{
cout << "exception occurred...";
cout << e.what() << endl;
}
catch (...)
{
error_msg = "Unknown exception";
cout << error_msg << endl;
}
m_connection.close();
return 0;
}
On Dec 5, 2007, at 1:00 PM, Clark Cox wrote:
On Dec 5, 2007 8:29 AM, Graham Reitz <email@hidden> wrote:
Thanks Tom,
That is what goes wrong - the passed in values don't survive
validation. Either one of them is uninitialized, they are in the
wrong order or don't belong to the same container.
Why does the exact same code and libraries run fine under the release
build?
This is the whole point of these extra checks. Many people do things
with the STL that *seems* to work, but which isn't guaranteed to work
by the C++ standard. Some examples of this that I have seen in
people's code:
1) Assuming that every iterator is just a pointer or can be
constructed from one (setting an iterator to NULL is a very common
example of this).
2) assuming that it is legal to compare iterators that don't belong to
the same container
3) assuming that you can decrement an input iterator, output iterator
or forward iterator
4) assuming that you can store a copy of an input iterator to
"remember your place"
...and many others.
Out of sheer luck (or lack thereof, when you really think about it),
many of these things will seem to work in many cases or on certain
platforms. The debug settings in GCC are being helpful by pointing
these problems out in debug mode (i.e. *before* you've shipped the bad
code to your customers).
You would be well served to leave these settings as they are, and to
track down every crash that they cause.
--
Clark S. Cox III
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden