Warren, Bill
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.
Alex
On Friday, October 06, 2006, at 02:25AM, Alex Burton <alexibu@stripped> wrote:
>Warren, Bill
>
>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.
>
>Alex
>
>On Thursday, October 05, 2006, at 05:12PM, Warren Young <mysqlpp@stripped>
> wrote:
>
>>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
>>for you.
>>
>>--
>>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
>
>
>
