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
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 O(1)
> 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