[vtk-developers] Proposal: Simplify vtkDebugLeaks registration
David Lonie
david.lonie at kitware.com
Fri Sep 9 09:27:04 EDT 2016
On Thu, Sep 8, 2016 at 6:11 PM, David Cole <DLRdave at aol.com> wrote:
> A few comments:
>
> That should be typeid(*this), and I'm uncertain if that works in the
> context of a base class constructor before the derived class's
> constructor is called. Does it? Doesn't seem like it should...
typeid will always resolve to the "current" class when called from a
constructor/destructor.
For science: http://codepad.org/WWweG8hk
#include <iostream>
struct Base
{
Base() { std::cout << typeid(*this).name() << std::endl; }
virtual ~Base() { std::cout << "~" << typeid(*this).name() << std::endl; }
void Init() const { std::cout << typeid(*this).name() << std::endl; }
};
struct Derived : public Base
{
};
int main()
{
Derived d;
d.Init();
return 0;
}
Output:
4Base
7Derived
~4Base
The second suggestion in my first email would move the construction
logic to something like the Init() method in that example, which
resolves properly to the Derived class.
> If you do end up tracking every instance, and printing them all at
> leak time, perhaps have a sane way of only printing **some** of them.
> Usually, when I end up with a leak, it's connected to a vast network
> of objects, and they all leak, with hundreds, if not thousands of
> objects leaking.
I agree, digging through the ::Print() output for 100's of objects
would not be useful for most cases! My plan for the object-based
report would be to iterate through the leaked objects, collect
classnames/counts, and print the summary just like it does now by
default. Optionally it could check an environment variable to print a
complete output with object details.
> Also, if you end up tracking every instance, it would be great to have
> an API to the leaks manager to count and iterate all the outstanding
> instances.
That would certainly be useful. Something like void
vtkDebugLeaks::GetCurrentObjects(vtkObjectBaseCollection *col) should
do the trick.
Personally I'm leaning towards the second option (collect strings but
use a centralized vtkObjectBase::InternalInit() method) as it's less
intrusive/less work.
Dave
More information about the vtk-developers
mailing list