Catching overriding methods with wrong signature

[Steve Folly]

Hi,

I had cause to change a base class virtual method's signature from const to
non-const and realised the compiler didn't warn me about derived classes
that hadn't changed:


class Base
{
public:
virtual void Foo() const;
}

class Derived : public Base
{
public:
virtual void Foo() const;
}


If I want to change Foo() to a non-const method I'll have to find all the
places where Foo() is overridden and change those as well. A daunting task
in a big project! And quite possible that some may be missed.

The ones I missed would of course be found eventually by testing, but if I
could catch them at compile time, so much the better.

Now, I haven't seen this in any FAQs, but if I've missed one that describes
my solution then I swear it's coincidence!

If I changed Base::Foo to be non-const, but left Derived::Foo const, the
compiler would not warn me. Fair enough. But, if I make Base:

class Base
{
public:
virtual void Foo();

class NotOverridable;
virtual NotOverridable* Foo() const { return 0; }
}


The compiler is nice enough to tell me the return type differs and is not
co-variant. Of course, NotOverridable should not be defined, and the method
still needs a body, otherwise a link error occurs because it's virtual. (Is
there any way around this?)

Does this seem like a good idea? It seems to work for my case, but is there
likely to be anything I've missed that might make this bad on a wider scale?


--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[Alf P. Steinbach]

* Steve Folly:

Hi,

I had cause to change a base class virtual method's signature from const to
non-const and realised the compiler didn't warn me about derived classes
that hadn't changed:


class Base
{
public:
virtual void Foo() const;
}

class Derived : public Base
{
public:
virtual void Foo() const;
}


If I want to change Foo() to a non-const method I'll have to find all the
places where Foo() is overridden and change those as well. A daunting task
in a big project! And quite possible that some may be missed.

The ones I missed would of course be found eventually by testing, but if I
could catch them at compile time, so much the better.

Now, I haven't seen this in any FAQs, but if I've missed one that describes
my solution then I swear it's coincidence!

If I changed Base::Foo to be non-const, but left Derived::Foo const, the
compiler would not warn me. Fair enough. But, if I make Base:

class Base
{
public:
virtual void Foo();

class NotOverridable;
virtual NotOverridable* Foo() const { return 0; }
}


The compiler is nice enough to tell me the return type differs and is not
co-variant. Of course, NotOverridable should not be defined, and the method
still needs a body, otherwise a link error occurs because it's virtual. (Is
there any way around this?)

Does this seem like a good idea?

For finding the earlier overrides, yes. Neat trick. Just be sure you
rebuild all.

It seems to work for my case, but is there
likely to be anything I've missed that might make this bad on a wider scale?

It wouldn't be nice to have that constraint imposed permanently.

I'd remove it after finding & correcting the earlier overrides, unless
instructed to not use any time at all on structuring for maintenance.

 

[Steve Folly]

For finding the earlier overrides, yes. Neat trick. Just be sure you
rebuild all.

Good point! (Visual Studio 2005 sometimes has a knack of not bothering to
recompile something that needs to be recompiled!)

It wouldn't be nice to have that constraint imposed permanently.

I'd remove it after finding & correcting the earlier overrides, unless
instructed to not use any time at all on structuring for maintenance.

Yes, that's what I thought. Unfortunately the code is in a common library
shared by many projects. I would rather not keep them permanently, but
rather than having to check each project now I will let each project accept
the changes to the common library and they can do it on their own slower
time.

I suppose I could take them out eventually...

Many thanks.

--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[Roland Pibinger]

I had cause to change a base class virtual method's signature from const to
non-const and realised the compiler didn't warn me about derived classes
that hadn't changed:

What about making the const version private?

 

[Alf P. Steinbach]

* Roland Pibinger:

What about making the const version private?

It can still be overridden. Access is orthogonal to "overridability".
The C++ experts who are religious about this are about evenly divided on
whether you should always make virtual member functions private, or
never make them private; the FAQ seems to be in the latter camp.

 

[Roland Pibinger]

* Roland Pibinger:

It can still be overridden. Access is orthogonal to "overridability".

Ok, at least it would give a compile-time error in the above case
whenever the function is called polymorphically. A better approach is
to change

class Base
{
public:
virtual void Foo() const;
};

to

class Base
{
public:
virtual void Foo() = 0;
};

Now he gets a compile-time error (when Foo() is called on a const Base
object) and a linker error for derived classes that don't implement
the non-const function.

 

[Gennaro Prota]

Hi,

I had cause to change a base class virtual method's signature from const to
non-const and realised the compiler didn't warn me about derived classes
that hadn't changed:


class Base
{
public:
virtual void Foo() const;
}

class Derived : public Base
{
public:
virtual void Foo() const;
}


If I want to change Foo() to a non-const method I'll have to find all the
places where Foo() is overridden and change those as well. A daunting task
in a big project! And quite possible that some may be missed.

The ones I missed would of course be found eventually by testing, but if I
could catch them at compile time, so much the better.

Actually, I'd expect any quality implementation to warn about the
function in the derived class hiding the (non-const) one in its base.
What compiler are you using?

 

[Steve Folly]

Actually, I'd expect any quality implementation to warn about the
function in the derived class hiding the (non-const) one in its base.
What compiler are you using?

Microsoft Visual Studio 2005

--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[Steve Folly]

Ok, at least it would give a compile-time error in the above case
whenever the function is called polymorphically. A better approach is
to change

class Base
{
public:
virtual void Foo() const;
};

to

class Base
{
public:
virtual void Foo() = 0;
};

Now he gets a compile-time error (when Foo() is called on a const Base
object) and a linker error for derived classes that don't implement
the non-const function.

I'm not sure this is better; derived classes don't have to override the
method. But I do want to catch them overriding the method with the wrong
signature.



--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[Gennaro Prota]

Microsoft Visual Studio 2005

Hmm :-( One can imagine various do-it-yourself solutions but... if you
have a chance to use gcc, give it a run using its -Woverloaded-virtual
option. The Intel compiler, if you have it, will also detect such
potential mistakes out of the box (and it will, more likely than gcc,
compile your Windows/MSCV-biased code on the spot, but of course it is
not free).