Sander Pilon writes:
>
>
[skip]
>
> I don't know if it works with the standard mysql++, as we use an
> internal mysql++ clone.
>
> Regards,
>
> Sander
>
Hi!
There is a patch for standard MySQL++ to enable it to be built and
used with STLPort.
I do not think that latest GNU 3 STL is any
> -Original Message-
> From: Sinisa Milivojevic [mailto:[EMAIL PROTECTED]]
> Sent: 26 October 2001 13:46
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Memory allocators / STL
>
>
> [EMAIL PROTECTED] writes:
> > Do you know if this is
[EMAIL PROTECTED] writes:
> Do you know if this is the case even with the GCC v3.0.1?
> What is the "recommended" combination of compiler / STL implementation in order
> to work properly with MySQL client?
>
> Thanks!
>
> /Stefan
>
Yes, it is as I use the same compiler.
MySQL client can be
Do you know if this is the case even with the GCC v3.0.1?
What is the "recommended" combination of compiler / STL implementation in order
to work properly with MySQL client?
Thanks!
/Stefan
Quoting Sinisa Milivojevic <[EMAIL PROTECTED]>:
> Hi!
>
> It is very well known that most C++ compiler
[EMAIL PROTECTED] writes:
> Hi!
>
> We are currently developing a MT server (pthreads based, the main thread
> does accept() and push_back to a vector that the threads pick up work from,
> the threads share a global hash_map of cached information protected by a
> pthread_rwlock) and we seem to h
Hi!
We are currently developing a MT server (pthreads based, the main thread
does accept() and push_back to a vector that the threads pick up work from,
the threads share a global hash_map of cached information protected by a
pthread_rwlock) and we seem to have an issue with confliting memory al