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, but statistics and logging too. For leak detection, there are enough tools which don't require any code changes. We already fixed a lot of memory leaks for 2.0.1 with this tools, which means that - it's possible - it's more easy now, because not so many leaks are reported - you find them for all objects, not only for special objects Malte. Frank Schönheit - Sun Microsystems Germany wrote: > Hi Daniel, > > >>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. > > >>>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. > > Ciao > Frank > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
