[Insight-developers] RE: const flood fill conversion

[Miller, James V (Research)]

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



> -----Original Message-----
> From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
> Sent: Monday, September 09, 2002 12:40 PM
> To: Miller, James V (Research); Insight-developers (E-mail)
> Subject: const flood fill conversion
> 
> 
> Ok, I've been experimenting with 
> FloodFilledFunctionConditionalIterator and 
> FloodFilledFunctionConditionalConstIterator. Everything seems to work 
> pretty much ok, except for:
> 
>   void Set( const PixelType & value)
>     { m_Image->GetPixel(m_IndexStack.top() ) = value; }
> 
> which produces the error:
> 
>    error C2166: l-value specifies const object
> 
> m_Image is protected member of ConditionalConstIterator, declared as:
> 
> ImageType::ConstPointer m_Image;
> 
> The rest of the code, in terms of the split between const and 
> non-const is 
> layed out fairly similarly to the neighborhood iterators. How can you 
> access a const member variable in a base class as a non-const 
> variable in a 
> derived class? Is there a trick I'm missing?
> 
> Thanks,
> -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.
>