[Insight-developers] itkNeighborhood and leaks

[Joshua Cates]

I can look into this. It might be reasonable.  But I want to avoid
introducing any unnecessary overhead with respect to copying and
construction of these objects, since they are often used in the
inner-loops of number crunching algorithms.

This brings up a larger issue. There is obviously a point where the use of
smart pointers is not necessary or desireable. My opinion is that
low-level objects used to write filters (itkImageIterator, itkVector,
itkHashTable, itkFunction, itkNeighborhood, etc) should not be subclassed
from itk::LightObject as a rule, but only where it makes particular sense
to do so.  Some objects like itkNeighborhood may then fall into the latter
category as their API's evolve.  This seems to be the pattern of
development currently in Itk.  We should probably discuss this issue more
a TCON so that we have a common understanding of what the standard really
is.

Josh.


On Thu, 26 Jul 2001, Bill Hoffman wrote:

> The IRIX purify is very broken, in fact, I would say it does not work at all.
> 
> "several places" may have been only one, but the point is I see no reason why this
> class should be an exception to the coding standards.   If it used ::New, the leak
> would not be there.   Is there a good reason for this class not to be an itkLightObject?
> 
> -Bill
> 
> 
> At 02:21 PM 7/26/2001 -0600, Joshua Cates wrote:
> >Hi,
> >
> >The only MLK I see associated with itkNeighborhood is 96 bytes in
> >itkDiscreteGaussianImageFilterTest.  Are there other places that I am
> >overlooking?  Oddly, this leak does not appear in the Irix run.
> >
> >Josh.
> >
> >_____________________________
> > Josh Cates                     
> > School of Computer Science     
> > University of Utah
> > Email: cates@cs.utah.edu
> > Phone: (801) 587-7697
> > URL:   www.cs.utk.edu/~cates
> >
> >