[Insight-developers] ConstPointers

[Luis Ibanez]

Hi Mark,

You are right,

This is an inconsistency problem that should be fixed.
It goes back to a year ago when we started enforcing
const-correctness on the "GetInput()" methods but didn't
go all the way down to include the GetOutput() methods.


The recipient of the filter->GetOutput() shouldn't be
allowed to modify the image. That will break the
consistency of the pipeline.

We could fix most of them by changing

              itkImageSource.h

where

   OutputImageType * GetOutput(void);
   OutputImageType * GetOutput(unsigned int idx);

should be

   const OutputImageType * GetOutput(void) const;
   const OutputImageType * GetOutput(unsigned int idx) const;

Most of the image filters inherit their GetOutput()
method from this itkImageSource class.


About the second assignment that you describe,
this seems to be something to fix on the SmartPointer
class itself. I would expect the declaration:

    SmartPointer &operator = (ObjectType *r)

in itkSmartPointer.h line 129 to take care of
the const case when SmartPointer is instantiated
over "const Self"...


All filters should take "const input images"
as input, since a filter is not supposed to
modify its inputs, just read data from them.




   Luis



---------------------
Mark Foskey wrote:

> There is what appears to be an inconsistency with SmartPointers and 
> const-ness.  You can do:
> 
>   ImageType* image = someFilter->GetOutput();
>   ImageType::Pointer imageSmart = image;
> 
> But you cannot do:
> 
>   const ImageType* image = someFilter->GetOutput();
>   ImageType::ConstPointer imageSmart = image;
> 
> Or at least, I can't do it with MSVC 6.0.  There is no operator=() 
> defined for that case.
> 
> I believe this has never come up because you rarely take a const image 
> as input since you might want to call its Update() method.  Perhaps we 
> should explicitly point that out to people trying to write filters.
> 
> Is this inconsistency a problem that should be fixed?
>