Nice one Alex.
I've tried the fix you mention and no problems on the memory front. However
as you imply, you shouldn't really pass a member variable object into the
base class constructor as it won't have been initialised yet. The MS C++
std library implementation allows you to do what I believe the original
intention was, as follows:
Query(Connection* c, bool te = true) :
success_ = true;
And this also seems to stop the memory usage building up. This seems to be
specific to Microsoft's implementation though- anyone know of a standard
From: Alex Burton [mailto:alexibu@stripped]
Sent: 06 October 2006 02:53
Subject: Re: mysql++ memory usage
My memory usage is now completely stable - thanks for both your help.
Morals to the story.
Prefer RAII - if the basic_ostream didn't have an init method it couldn't
have been mis used.
Don't attempt to stir in a bicycle when a recipe asks for a cup of sugar.
0 can in no way be considered a pointer to a stream buffer.
The basic_ostream doesn't appear to attempt to do anything with the stream
buffer during the constructor, but it might so it would be good to make sure
that the stream buffer were already constructed.
Anyway found the problem not entirely sure of the best fix.
On Friday, October 06, 2006, at 02:25AM, Alex Burton <alexibu@stripped>
>I have managed to modify the mysql++ code to remove the problem.
>In the query ctors, instead of initialising the base class with
std::ostream(0) and then calling init(sbuffer_) in the body of the ctor,
just initialise with std::ostream(sbuffer_).
>I havent looked through the visual c++ standard code enough to be able to
explain it completely, but calling std::ostream(0) and then calling init
effectively calls basic_ostream::init twice. Initialising the stream twice
must be what is causing the problem.
>An alternative would be to default construct std::ostream and then call
init, but don't call std::ostream(0) and then init.
>I'm not sure what the meaning of calling std::ostream(0) is anyway.
>I am not sure what effect this change would have on mysql++ using other
implementations of the c++ standard library, but from looking at the code in
the gnu standard library, it looks like it will all work the same - except
that it doesn't leak when you call init twice apparently.
>On Thursday, October 05, 2006, at 05:12PM, Warren Young
>>Bill K wrote:
>>> I agree, I do not see the problem to be with MySQL++
>>I'm not entirely convinced of that, either. While MySQL++ proper may
>>not be leaking the memory, it may be possible to change it to avoid the
>>symptom. Until all those tests are tried, we don't know that, either.
>>But, this is not my itch: I don't use MySQL++ on Windows. At this
>>point, my limit is suggesting places to look for the workaround, or
>>things to try that will indirectly show where the workaround may be
>>found. Until someone finds that workaround, it'll be up to individual
>>MySQL++ users to come to their own accommodation with this CRT
>>feature/bug. That would be unfortunate, but I can live with it.
>>It's a similar situation with threading, only the thread question is
>>farther along: thread-safety also isn't my itch, but there's a document
>>stating what we have to do to be thread-safe w.r.t. the MySQL C library,
>>so I have a development plan to make MySQL++ take care of some of this
>>MySQL++ Mailing List
>>For list archives: http://lists.mysql.com/plusplus
>>To unsubscribe: http://lists.mysql.com/plusplus?unsub=1
>MySQL++ Mailing List
>For list archives: http://lists.mysql.com/plusplus
>To unsubscribe: http://lists.mysql.com/plusplus?unsub=1
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus