Hello Frank, > Is there a canonic place where this is is OSL_ASSERTEd (application > shutdown), or do I always have to explicitly use checkObjectCount?
There is only inline code, the LeakGuard references static data (rtl::Static), which OSL_ASSERTs upon shutdown (assuming _all_ objects are destructed). I have added checkObjectCount() to check at runtime how many objects are expected to be alive. > The already-mentioned tools-macros had some other cool feature, which I > could imagine here: Upon app shutdown, a list was written which > contained information about all classed equipped with the DBG_XTOR > macros, stating the number of objects created, destroyed, max.existing > at a time, and leaked. While probably only the latter information is > really useful, it might be interesting to have such detection > capabilities for the LeakGuard, too. > But well, perhaps this is an issue for the yet-to-come consolidation of > the TOOLS/OSL diagnostics. IMO it is better to separate those statistics into another class, so the purpose of LeakGuard remains clear: finding leaks, not doing statistics. > Do you have any guestimations about the impact on runtime-performance > even in non-pros, if this would be extensively used? Default is just counting (which comes down to an extra osl_incrementInterlockedCount()/osl_decrementInterlockedCount() for every object creation/destruction), so I _assume_ in general this does not hurt. When storing addresses, this is different; I use a std::hash_set and a osl::Mutex to serialize accesses. > I mean, I'm tempted to re-fit all my UNO implementations with this > class, and those alone would probably be several hundreth classes. If > everybody would be doing this - would we have a problem in non-pros? Of course, nobody can answere this for sure. >>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. > > > 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... regards, -Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
