Hello Frank,
>>IMO it is better to separate those statistics into another class, so the
>>purpose of LeakGuard remains clear: finding leaks, not doing statistics.
>
>
> 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 process
shutdown. IMO statistics like "how many objects have been created,
destructed" ought to be shifted into another diagnostics class, keeping
the purpose of LeakGuard clear.
>>>Definately yes. If the diagnostics-consolidation is ever going to
>>>happen, and if we have a mature set of full-fledged diagnostic tools in
>>>OSL then, I'd appreciate this class being moved to OSL, too.
>>
>>Why osl? IMO rtl is the right place for this. One could think of
>>salhelper (because of the C++ notion), but then we cannot use this in sal...
>
>
> Uhm, don't really care. Just assumed OSL because I think it could be
> part of a "diagnostics framework", and today's diagnostics are in OSL.
Good point. So LeakGuard ought to be in osl/diagnose.hxx?
And what about a different name?
class C : private osl::leak_guarded<C> {...};
regards,
-Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
