I like leak detection, but I think inheritance is not so useful here,
because you can't simply add leak detection to a class 'on demand',
without compiling all following modules.
We already have some leak detection in tools/debug.hxx:
DBG_CTOR and DBG_DTOR.
Together with DBG_CHECKTHIS, you can also use it to check if your object
is still valid.
Advantage: No inheritance
(Small) Disadvantage: Manually put DBG_CTOR/DTOR in all ctors and dtors.
So maybe you would like to extend the things we already have in tools...
Malte.
Daniel Boelzle wrote:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
