List:MySQL++« Previous MessageNext Message »
From:Izzy Date:September 29 2008 3:57pm
Subject:Re: Fwd: possible bug
View as plain text  

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 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
> arrays).
> 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
> classes.*).
> 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...
> Rick
> 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.
>> Joel
>> 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:
> To unsubscribe:
Fwd: possible bugJim Graf26 Sep
  • Re: Fwd: possible bugMickaël Wolff26 Sep
    • Re: Fwd: possible bugIzzy28 Sep
      • Re: Fwd: possible bugMickaël Wolff28 Sep
      • Re: Fwd: possible bugJoel Fielder29 Sep
        • Re: Fwd: possible bugRick Gutleber29 Sep
          • Re: Fwd: possible bugJoseph Artsimovich29 Sep
          • Re: Fwd: possible bugAndrew Sayers29 Sep
          • Re: Fwd: possible bugIzzy29 Sep