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 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.
Ehm, yes - that's what I tried to say. I agree that the semantics of the
LeakGuard should be kept clear and straight-forward. But this so far
doesn't disallow doing shutdown-time statistics of *leaked instances*,
does it? Everything else (instances created and the like) is indeed not
in the scope of a LeakGuard.
>>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?
let's not put too much into a single file ...
If we agree that Leakguard is a diagnose tool like OSL_*, then it should
be in module osl (or in the same module as later, new, diagnostics
helpers), too. Else, I don't really care whether osl or rtl ...
> And what about a different name?
>
> class C : private osl::leak_guarded<C> {...};
Don't have an opinion on this ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
