[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-
>>
>>