For some reason, my e-mail client doesn't reply to the list by default...
-------- Original Message --------
I understand what you are saying. I figured it was just an opportunity
for some needed STL cheerleading from a former decrier of STL. :-)
I've changed my mind on the fundamental value of STL, although I still
have some philosophical issues with it, most of which cannot be resolved
without creating a whole new language (which may in fact have been a
better idea than what C++0x is turning out to be, but that's a whole
It seems to me that everyone seems to have missed the obvious question:
When you are using the default constructor, which means it will throw
exceptions, are you initializing the connections in a try block?
If you aren't and an exception is thrown and not handled your program
will bomb (in the case of Windows, I believe a system model dialog comes
up with a message about an unhandled exception, in *nix, the program
just abends. When I took over the project I'm working on now, it was
rife with instances of unhandled exceptions, which went a long way to
explaining the numerous mysterious crashes that would often occur.
When you described your solution, you didn't explicitly say that the
for(int i = 0; i< 20; i++)
pCon[i] = new mysqlpp::Connection(true);
only that you didn't have success until you explicitly defined the
default parameter. In your example it was set to false, not true as I
As Chris Fey pointed out, it seems you may just be masking the problem
by hiding the exceptions (my predecessors originally did a lot of that
too, using a catch block that did nothing). Proper exception handling
is imperative to using MySQL++ correctly and avoiding crashes. Unless
we can find out what was actually happening in your _original_
implementation, I don't think we can adequately explain what's happening
or determine the best way to fix it.
All else being equal, there doesn't seem to be anything inherently wrong
with using an array like you are. I wouldn't do it, but I don't believe
that's the cause of your problems.
p.s. Your Cult of the C++ Templates membership dues are late. Please
remit payment at the Church of St. Stroustrup at your earliest convenience.
> I have no problems or fears using STL, I am also using vectors, list
> etc in my projects. Actually I'm using also simple arrays as STL, so I
> have mixdown of arrays and STL in program.
> Depending of what I need, I use or simple arrays or STL. I just wanted
> to use fix number of connections to mysql, and the simplest way to
> implement something
> like that is that you define mysqlpp::Connection cons[ 64 ];
> Yes I could use list also to declare connection list, but this seemed
> to me the simplest and fastest way to do it.
> I don't want to flame the war between STL and arrays, pro and contra.
> I just wanted to notice that maybe there is possible bug in mysql++, I
> have never claimed that there is. Just possibility.
> Also I had solved the problem after some time, but I had a great
> difficulty to find out what was causing the trouble.
> The problem was that I hadn't declared the constructor so the default
> constructor was called, and after that point something gone wrong.
> If I declared constructor as true or false (throw or not the
> exceptions) everything was ok.
> But if I didn't I have catched the exceptions, "MySql gonne away".
> Maybe it is the bug in mysql++, or maybe the problem is somewhere in
> my project settings, I don't know.
> I have multi-threaded service that do some things with mysql. Maybe
> that is the problem, but then declaring or not the constructor seems a
> illogical to cause all the trouble. But it does.
> On Mon, Sep 29, 2008 at 4:58 PM, Rick Gutleber <rgutleber@stripped> wrote:
>> I have a hard time believing the STL <vector> has anything more than an
>> penalty over the raw C-type array for any operation, and probably not even
>> that for most (and that's ignoring all the things you can't do with C
>> Izzy, you need to get over your prejudice and embrace STL. It is not
>> without its problems and pitfalls, but it will do what you need, how you
>> need it, and as fast as you need it. I speak from experience. Having done
>> C++ since the early 90s, I was very prejudiced against templates because
>> before C++ 98 adoption was wide-spread, every compiler implemented them
>> somewhat differently, and the fact is templates are a wart to work around
>> C++'s segregated data types (C data types vs objects): the C data types
>> cannot be fully used in an OOP way without them.
>> I also didn't care for the overly terse and occasionally inconsistent naming
>> in the STL methods, preferring my own container class implementation based
>> on good old inheritance and macros I'd developed back in the mid and late
>> 90's (For instance, a single iterator object worked for all container
>> Nevertheless, I have been dragged kicking and screaming into the 21st
>> century and found the benefits far outweigh the disadvantages. Forget your
>> fears, embrace the Future! Join us, join us, join us...
>> p.s. It's not cult. Really. ;-)
>> * The new C++0x "auto" keyword (overloading it from its original C meaning)
>> has me all atwitter in anticipation.
>> Joel Fielder wrote:
>>> mysql++ is described on its website thus: "A C++ API for MySQL. Tries to
>>> make working with queries as easy as working with other STL containers."
>>> If you don't want to use C++ techniques or STL-type containers, then it's
>>> definitely the wrong choice for you!
>>> Besides, isn't std::vector pretty much just an array anyway once it's been
>>> through the pre-processor? And I'm not sure speed is ever a good reason to
>>> reject containers out of hand, especially in database applications.
>>> Izzy wrote:
>>>> why shouldn't I use them? With the arrays I have direct access to
>>>> memory location of the array, while
>>>> using containers looping with iterators take a precious CPU time.
>> MySQL++ Mailing List
>> For list archives: http://lists.mysql.com/plusplus
>> To unsubscribe: http://lists.mysql.com/plusplus?unsub=1
|• [Fwd: Re: Fwd: possible bug]||Rick Gutleber||29 Sep|