[Insight-developers] const inputs in Image Filters

[Miller, James V (CRD)]

Well, then if you really feel the const inputs are an important
way the toolkit will be used, then here is another issue:

GetOutput() should also return a const smart pointer. Using your argument for 
GetInput(), we shouldn't allow anyone to modify the output of a filter. Only a 
filter should be able to modify its output.  No-one should be allowed to grab the
output to a filter and modify it without the filter's knowledge. This is the 
only way to ensure the integrity of the data in the pipeline.

'Course, doing this means that the filter itself will not be able to modify
its output so either every GenerateData() or ThreadedGenerateData() will 
have to const_cast the pointer or a separate API (in the protected section 
of ProcessObject) will have to be created so a filter can get its own output.

In my experience, const gets in the way more that it helps. I would definately
say that it is harder to properly manage than using traits. Especially when
you consider the amount of code duplication that just went into the system
to create Const versions of the various Image iterators.



-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Monday, March 25, 2002 6:00 PM
To: Miller, James V (CRD)
Cc: Insight Developers
Subject: Re: [Insight-developers] const inputs in Image Filters


Jim,


Miller, James V (CRD) wrote:

>Well, I guess the big question is: when are people going to have
>const images?
>
Every time they write a function/method that receives
an image and does not expect to modify the image !!!

>I haven't had a need for them in any of the code I have written with 
>ITK. So my opinion is biased away from supporting const images.
>
It seems that all this time writing small test programs for
our collection of 280 test files have make us believe that
the normal use of ITK will be to write applications of 100
lines that open a file, read an image, run one filter and
write the output image to a file.  

I certainly hope that this will not be the normal use of ITK !

We should keep in mind the real use of the toolkit for applications
that do something useful. Any serious application will be made of
more than just the main() {}.

If it is done correctly, any real application will have a large amount
of non-ITK classes with their respective methods and it is to expect
that parameters passed to these functions will use "const" correctly.

ITK filters will be a minor component of a full fledged application
and it will be a bit embarrassing to have to tell to these programmers
that they have to down cast their const-correct applications because
ITK is lax in const typing.

Keeping const-correctness is not harder than respecting any other type.
It is not harder than using Traits correctly.
 

   Luis