[Insight-developers] RE: [Insight-users] Bug in itkFloodFille dFunctionConditionalItera tor

[Damion Shelton]

Ok, I'll try to convert the flood fill function classes and see what 
happens.

-Damion-

--On Monday, September 09, 2002 11:19 AM -0400 "Miller, James V (Research)" 
<millerjv@crd.ge.com> wrote:

> The issue here is that when the const versions of all the iterators
> were created, the code was just duplicated into disjoint classes.
> What should have happened was that the non-const versions should have
> subclassed the const versions, only added the methods to "set" the
> items under the iterator.  This way the algorithm would only exist
> in one place.
>
> This is a problem with many of iterator classes. The exception I believe
> is the NeighborhoodIterator heirarchy, which does have the non-const
> versions inherit from the const versions.
>
>
>
>> -----Original Message-----
>> From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
>> Sent: Monday, September 09, 2002 11:12 AM
>> To: Miller, James V (Research)
>> Subject: Re: [Insight-developers] RE: [Insight-users] Bug in
>> itkFloodFilledFunctionConditionalItera tor
>>
>>
>> Could you elaborate? When the flood fill stuff was converted
>> to const and
>> non-const (originally by Bill Lorensen according to the CVS
>> logs) this
>> wasn't done - is there a reason why it wouldn't work for the
>> flood fill? I
>> assume the "meat" of the algorithm has to avoid references to
>> const/non-const?
>>
>> Thanks,
>> -Damion-
>>
>> --On Monday, September 09, 2002 9:28 AM -0400 "Miller, James
>> V (Research)"
>> <millerjv@crd.ge.com> wrote:
>>
>> > This is why the non-const versions should be subclasses of the const
>> > versions (with the meet of the algorithm kept in the const version).
>>
>