List:MySQL++« Previous MessageNext Message »
From:Matt Dargavel Date:October 6 2006 11:33am
Subject:RE: mysql++ memory usage
View as plain text  
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) :
	std::ostream(std::_Noinit),
	OptionalExceptions(te),
	Lockable(false),
	def(this),
	conn_(c),
	success_(false)
	{
		init(&sbuffer_);
		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
way?  


-----Original Message-----
From: Alex Burton [mailto:alexibu@stripped] 
Sent: 06 October 2006 02:53
To: plusplus@stripped
Subject: Re: mysql++ memory usage

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
>
>
>

-- 
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