[Insight-developers] error in FloodFilledSpatialFunctionCondi tionalIterator

[Miller, James V (Research)]

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-
> 
> Miller, James V (Research) wrote:
> 
> >I made the change to Get() so that it matched the prototype of 
> >the superclass. One of the compilers was complaining about the 
> >signature of the function changing as it went down the class 
> >hierarchy.
> >
> >
> >
> >  
> >
> >>-----Original Message-----
> >>From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
> >>Sent: Tuesday, September 24, 2002 1:53 PM
> >>To: 'insight-developers@public.kitware.com'
> >>Subject: [Insight-developers] error in
> >>FloodFilledSpatialFunctionConditionalIterator
> >>
> >>
> >>Hi,
> >>
> >>It appears that some changes made to 
> >>FloodFilledSpatialFunctionConditionalIterator last week are causing 
> >>build problems in our code. Specifically:
> >>
> >>PixelType & Get(void)
> >>
> >>was changed to
> >>
> >>const PixelType & Get(void) const.
> >>
> >>The former compiles correctly in the blox code while the 
> latter does 
> >>not. I'm not sure why this isn't showing up in the 
> >>dashboards, since it 
> >>should affect the test as well (the code causing the problem is in 
> >>BloxCoreAtomImage.txx, which is exercised by 
> >>/BasicFilters/BloxCoreAtomTest.cxx).
> >>
> >>In any case, the problem seems to be that the new version of 
> >>the Get() 
> >>function enforces a const return type while the existing 
> code assumed 
> >>that Get returned an object that could be modified; i.e. 
> >>myIterator.Get().SetFoo(value);
> >>
> >>Am I misinterpreting what's going on? Any suggestions?
> >>
> >>Thanks,
> >>-Damion-
> >>
> >>_______________________________________________
> >>Insight-developers mailing list
> >>Insight-developers@public.kitware.com
> >>http://public.kitware.com/mailman/listinfo/insight-developers
> >>
> >>    
> >>
>