[Insight-developers] RE: const flood fill conversion

[Lorensen, William E (Research)]

I added a couple of missing typename's for gcc.

-----Original Message-----
From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
Sent: Monday, September 09, 2002 3:06 PM
To: Miller, James V (Research); Insight-developers (E-mail)
Subject: [Insight-developers] RE: const flood fill conversion


Thanks, the const_cast worked great. I've converted over the conditional 
iterator hierarchy and the tests build fine under Windows; please let me 
know if the changes cause unexpected behavior anywhere else.

Under the non-const deriving from const scheme, it looks like 
FloodFilledFunctionConditionalIterator is an unnecessary class (no classes 
ever derive or should derive from it). ConditionalIterator is also 
unnecessary right now but might(?) be useful in the future. Anyone 
agree/disagree?

-Damion-

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

> You can break the "const"-ness using a const_cast<>
>
> void FloodFilledConditionalIterator::Set() would look something like
>
> void Set( const PixelType & value)
> { const_cast<ImageType
> *>(m_Image.GetPointer())->GetPixel(m_IndexStack.top() ) = value; }
>
> Presumably it should be "okay" for this subclass to cast away the
> constness since the goal of this subclass is to allow writable access to
> data.
>
> This is presuming that no one ever creates a
>
> FloodFilledConditionalIterator<const Image<short, 2>>
>
> where they are trying to walk a constant image rather than trying to walk
> an  writable image as read-only.
>
> Another approach would be for the superclass not to store a constant
> pointer  but only allow read access to the image via the public API.
>
> Jim
_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers