[Insight-developers] error in FloodFilledSpatialFunctionCondi tionalIterator

Damion Shelton dmshelto@andrew.cmu.edu
Tue, 24 Sep 2002 14:45:03 -0400


Thanks, that did the trick.

-Damion-

Miller, James V (Research) wrote:

>The issue may have been an missing "const" on the end of the method.
>I had to go into the code multiple times to clear these up.
>
>In C++, a function can only be overridden in the prototype matches
>exactly.  If the prototype is slightly different, then the function
>is overloaded not overridden.  Unfortunately, the return type of a 
>overridden function cannot change.  So if 
>
>class A
>{
>public:
>  virtual const PixelType & Value(void);  
>};
>
>class B : public A
>{
>public:
>  PixelType & Value(void);   // error! return type changed
>}
>
>But the following code should be okay
>
>class A
>{
>public:
>  virtual const PixelType & Value(void) const;  // not the const at the end
>};
>
>class B : public A
>{
>public:
>  virtual PixelType & Value(void);   // creates an overloaded version
>}
>
>However in this second case, B creates an overloaded function that
>hides the version in A and hence produces a warning. So the correct
>B would have to be
>
>class B : public A
>{
>public:
>  virtual const PixelType & Value(void) const;  // need to reimplement the parent's version
>  virtual PixelType & Value(void);   // creates an overloaded version but the parent's version is not
>longer hidden
>}
>
>The bottom line is that I may have been overzealous in my changes.  Try defining the Get() method in
>the subclass as non-const and returning a non-const.  But also re-implement the subclass'
>implementation so we avoid the "method hiding method from superclass warning".
>
>Jim
>
>  
>
>>-----Original Message-----
>>From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
>>Sent: Tuesday, September 24, 2002 2:23 PM
>>To: Miller, James V (Research)
>>Subject: Re: [Insight-developers] error in
>>FloodFilledSpatialFunctionCondi tionalIterator
>>
>>
>>The superclass is the const version of the iterator, so if it matches 
>>the signature of the const-version prototype, does that 
>>unneccessarily 
>>enforce const-ness in the non-const derived class?
>>
>>-Damion-
>>    
>>