Hi Malte,
My concern here is: You do memory leak detection for *some* special
classes and don't find *other* leaks.
Is this really what you want to do?
Usually, my UNO implementations are most prone (by far) to leaking,
since it's pretty easy to have some cyclic references between two or
Hello,
talking offline here in Hamburg, we agreed that it makes sense to add
such a class. Special tests with external tools (valgrind,
BoundsChecker) are valuable, but may not cover a problematic program
path leading to leaks, because those tests are most often run by
developers. Using the
Hello Malte,
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.
There is no need to recompile derived classes/modules, because the
LeakGuard-ed class references
Malte Timmermann [EMAIL PROTECTED] writes:
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
Hi Daniel,
I'd like to present/discuss a recent helper, called rtl::LeakGuard which
helps to find leaking free store objects.
To cite Thorsten: Great stuff!
In non-pro builds, the LeakGuard OSL_ASSERTs any undestroyed (leaking)
objects while in product builds the LeakGuard class is just
We should talk about the LeakGuard when consolidating the debug macros,
as Frank suggested.
Please don't introduce before.
I also suggest to have a macro for it, which simply expands to nothing
in product builds.
If we do anything in this direction, I think it shouldn't be only leak
detection,
Hi Daniel,
Well, at least the last point of the statistics (the only one I ever
used: the number of leaked objects) serves exactly this purpose. It
would, for instance, enabled QA to regularily do leak tests on certain
usage scenarios.
LeakGuard OSL_ASSERTs if the object count is non-zero upon
Hi Malte,
We should talk about the LeakGuard when consolidating the debug macros,
as Frank suggested.
Please don't introduce before.
Uh. Let's not wait for something which perhaps happens in 2007.
Introduce it when it's there, and when it's needed: now.
I also suggest to have a macro for
Hi Malte,
We should talk about the LeakGuard when consolidating the debug macros,
as Frank suggested.
Please don't introduce before.
Uh. Let's not wait for something which perhaps happens in 2007.
Introduce it when it's there, and when it's needed: now.
I also suggest to have a macro for
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
10 matches
Mail list logo
