Hello,
I'd like to present/discuss a recent helper, called rtl::LeakGuard which
helps to find leaking free store objects. The helper works by embracing
the CRTP (curiously recurring template pattern), e.g. you use it like
class MyClass : private rtl::LeakGuard<MyClass> {...};
This creates static informtation about created and destructed MyClass
objects.
In non-pro builds, the LeakGuard OSL_ASSERTs any undestroyed (leaking)
objects while in product builds the LeakGuard class is just plain empty
(and does not hurt performance).
The LeakGuard class has three modes:
- LEAKGUARD_COUNT (default): just counts the number of instances
- LEAKGUARD_STORE_ADDRESSES: stores all addresses of created objects
[- LEAKGUARD_NONE: empty LeakGuard class for product builds]
LEAKGUARD_STORE_ADDRESSES has the advantage to iterate over all
instances using your debugger, but the disadvantage of using more memory.
You can explicitly switch the mode in your code, e.g.
class MyClass : private rtl::LeakGuard<MyClass,
rtl::LEAKGUARD_STORE_ADDRESSES>
or override the default mode placing a
CDEFS += -DRTL_LEAKGUARD_DEFAULT_MODE=LEAKGUARD_STORE_ADDRESSES
in your makefile.pmk (or similar).
If you are interested in checking the current (static) object count of a
LeakGuard-ed class, you can do so by calling the (static) member function:
static bool checkObjectCount( ::std::size_t nExpected = 0 );
which asserts if the observed object count is not the expected.
You can have a look at the implementation on cws presfixes10 (tag
cws_src680_presfixes10):
sal/inc/rtl/leakguard.hxx
I have added the header to sal, because I think such a guard can be
useful for lots of code, also in very basic libraries. IMO, there is
currently the problem, that headers of sal/cppu/etc will get a
(published into the concrete) part of the SDK. So I have tagged all of
leakguard's inner definitions as @internal, thus nobody ought to rely on
it staying compatible. We ought to expand the concept of
public/published API to the fields of C/C++/Java API, do we?
leakguard.hxx depends on e.g. osl/diagnose.h, so I can not put it into a
lower module than sal.
So what do you think? Comments, please.
regards,
-Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
