[Insight-developers] Purify errors

[Miller, James V (CRD)]

I would call Fill() on the parameters in the constructor of the 
CostFunctions

-----Original Message-----
From: Luis Ibanez
To: Miller, James V (CRD)
Cc: Insight-developers (E-mail)
Sent: 3/6/2002 11:49 AM
Subject: Re: [Insight-developers] Purify errors

Jim,

It seems that we have several of the UMR purify errors on the new 
structure for
CostFunctions and ImageMetrics.

Right now, the CostFunction has ivars for Derivatives (an itk::Array) 
and for
parameters.  Those arrays are not initialized until somebody call 
GetDerivative();

That doesn't seems to be a problem because the only way to get access to
the
Derivative is through this method and it will take care of initializing 
the Derivative
with the actual current value.

However, it will be just fine to initialize the derivative in the 
Constructor by
calling Fill(0) on it. Another option is to include the initialization 
in the itk::Array.
constructor. The drawback of this last option is that it will add some 
time penalty
at construction time for the Arrays. The advantage is that this will 
cover all the
classes using itk::Arrays .

Comments ?


Luis


=====================================================
Miller, James V (CRD) wrote:

> People,
>
>  
>
> As of last Friday, I had the Purify errors on the Dashboard down to 
> 111 (which was down from 8000).
>
>  
>
> In the last few days, the number of Purify errors has increased to
235!
>
>  
>
> For the people that have been checking in code over the last few days,

> please look through the Purify
>
> errors and try to address the errors you introduced.  If you cannot 
> decipher the error send me a note and
>
> I will guide you through.
>
>  
>
> Most of these errors are in the non-critical category. They are mostly

> uninitialized memory copies and
>
> uninitialize memory reads. These particular UMR and UMC errors may be 
> benign.  I can suppress
>
> certain errors if they outside of our control.
>
>  
>
> These purify results were computed using a RelWithDebInfo build on the

> Intel C++ 5.0 compiler.  It produces
>
> a few more UMC's than Microsoft Visual C++. One case in particular 
> that the Intel compiler produces a UMC
>
> where the VC++ does not is in copy "empty" structures.  An empty 
> structure is of the form
>
>  
>
> struct foo {};
>
>  
>
> These are used in parts of the code to force particular overloaded 
> functions to be called. If they are passed
>
> by value, a UMC occurs.  This is because all data structures have to 
> take up "some" space, usually a word.
>
> But since the structure has no ivars, there is nothing to initialize 
> programatically. I have changed some of these
>
> over to being passed by reference (const reference in particular) 
> which avoids the UMC error.
>
>  
>
> Another popular error is having a std::vector (or a std::queue, etc) 
> of itk::Vector's. The default constructors
>
> for itk:Vector does not initialize the memory.  So when a vector 
> resizes, a UMC error occurs on the "unused" portion of the previous 
> allocation. This is an example of one of the errors that I suppress by

> hand.  I just
>
> need to know where all of them are.
>
>  
>
> Finally, classes that have a template parameter that used for an ivar 
> accessable from a Set macro
>
> will produce a UMC when the Set is called and the template parameter 
> is something like an itk::Vector.
>
> Since the ivar datatype is a template parameter, we cannot assume a 
> particular initializer and we have
>
> to rely on the default constructors.  Here are some possible
solutions:
>
>  
>
> 1) Assume the tempate parameter is going to be a subclass of 
> itkFixedArray or itkArray and call
>
> Fill() on all these ivars in your constructor.
>
>  
>
> 2) Don't use a template parameter for this and force people to use 
> itkFixedArrays or itkArrays.
>
>  
>
>  
>
>
> *Jim Miller*
> */_____________________________________/*
> /Visualization & Computer Vision
> GE Corporate Research & Development
> Bldg. KW, Room C218B
> P.O. Box 8, Schenectady NY 12301
>
> _millerjv@crd.ge.com <mailto:millerjv@crd.ge.com>_/
> /(518) 387-4005, Dial Comm: 8*833-4005, /
> /Cell: (518) 505-7065, Fax: (518) 387-6981/
>
>
>  
>