Gary Anderson wrote:
> When the application exits, I seem to have a lot of
> un-released memory (leaks) that appear to be holding items read from the
> database during processing.
Whenever you think you have a leak, it's essential that you take the
next step, which is to correlate memory use with some work unit. Does
memory use go up as a function of time, or query count, or rows
retrieved, or what? If it remains fixed, it's "overhead", not a "leak".
There is known overhead in the MySQL C API library, and a memory
debugger is going to show it as a "leak" because it doesn't know better.
There's a way to release it -- see the C API docs -- but since most
programs have to access the database for their entire run time, there's
not much point in doing it; any platform MySQL runs on is going to have
decent memory management, so it releases unfreed memory at exit. As a
result, we don't bother to expose this as a feature in MySQL++.
> The manual indicates that a ResUse object
> contains a purge() method to release the resources held by the object,
This isn't generally needed. It's more an implementation detail than
anything else. A quick glance at the source shows that ~ResUse() calls
it, so if you have a leak due to not calling purge(), you really have a
leak due to not destroying your ResUse objects.
> but I can't seem to find similar methods for Result,
Result derives from ResUse.
> ...Row or Query. Do such methods exist?
You mean other than the destructors?
> If not, how is this allocated memory freed?
The same way memory is freed in any C++ program.
