[Insight-developers] Const/nonConst Iterator

[Miller, James V (Research)]

I am assuming in your code below that instead of 

ImageConstIterator< ImageType >  it( myConstImage, region );
it.GoToBegin();

you meant

ImageIterator< ImageType >  it( myConstImage, region );
it.GoToBegin();

So a non-const iterator can be passed a const image and will
allow someone to call Set() to a const image.

I think the solution is in the non-const version provide 
a constructor that takes a const Image but put that constructor
in the private section so that it can never be called.


-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
Sent: Wednesday, April 17, 2002 1:51 PM
To: Insight Developers
Subject: [Insight-developers] Const/nonConst Iterator


Hi 

I ran into the following problem when trying to make the 
non-const iterator derive from the const-iterator:


1) the const iterator has a constructor that accepts a
    (Const ImageType *)


2) the non-const iterator has a constructor that accepts
    a non-const  (ImageType *).

3) the non-const iterator add the method Set()


The only two methods in the non-const version are the
constructor and the Set() method.  So, far everything is
quite good.


but... because the non-const iterator can still have access
to the constructor with const ImageType * it is possible to
write the following code without getting any compiler 
warnings:


ImageType::ConstPointer   myConstImage;

ImageConstIterator< ImageType >  it( myConstImage, region );
it.GoToBegin();

it.Set( 200 );  <== Here the constness of the image is violated !!



It seems that the non-const version of the iterator should not
derive from the const version but rather both of them should
derive from a common class.  That will also allow to manage
properly some ivars that should be const in one interator and
non-const in the other.



  Luis


--------------------------------------------------------

Lorensen wrote:
> Why not make the nonconst iterator a subclass of the const one, 
> overriding the appropriate methods. I
> would hold off on introducing a new concept like a walker...




_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers