List:MySQL++« Previous MessageNext Message »
From:Alex Burton Date:October 6 2006 1:25am
Subject:Re: mysql++ memory usage
View as plain text  
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
>
>
>
Thread
mysqlpp and wchar_t problemgani b. c.2 Oct
  • Re: mysqlpp and wchar_t problemWarren Young2 Oct
    • mysql++ memory usageAlex Burton3 Oct
      • Re: mysql++ memory usageWarren Young4 Oct
      • Re: mysql++ memory usageBill K4 Oct
        • Re: mysql++ memory usageAlex Burton4 Oct
        • Re: mysql++ memory usageWarren Young4 Oct
          • Re: mysql++ memory usageBill K5 Oct
            • Re: mysql++ memory usageWarren Young5 Oct
              • Re: mysql++ memory usageAlex Burton6 Oct
                • Re: mysql++ memory usageAlex Burton6 Oct
                  • RE: mysql++ memory usageMatt Dargavel6 Oct
                    • Re: mysql++ memory usageWarren Young6 Oct
                      • Re: mysql++ memory usageAlex Burton7 Oct
                        • Re: mysql++ memory usageWarren Young7 Oct
                        • Re: mysql++ memory usageMatt Dargavel7 Oct
                          • Re: mysql++ memory usageWarren Young12 Oct
                            • Exporting classesMatt Dargavel19 Oct
                              • Re: Exporting classesWarren Young20 Oct
                                • RE: Exporting classesMatt Dargavel20 Oct
      • Re: mysql++ memory usageCarlos Flores4 Oct
    • Re: mysqlpp and wchar_t problemgani b. c.3 Oct