[vtk-developers] Proposal: Simplify vtkDebugLeaks registration

[David Lonie]

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