Re: Run-time-checking whether a pure virtual function has been implemented
mzdude wrote:
On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
Nordl?w wrote:
Is it possible to do runtime-checks whether a virtual base-class pure
virtual function has been implemented in an inherited class?
Run-time? Check? Why? Besides, what would be the point? If you have
the object, it can't be of the abstract base type, can it? An object
cannot be instantiated with the type that is abstract. If you have the
pointer to the base class, the virtual function table (the usual way to
implement the mechanism) contains the pointer to the final overrider for
that function, not the unimplemented pure 0...
What problem are you trying to solve?
I take to mean
#include <iostream>
using namespace std;
class Foo {
public:
virtual void bar() = 0 { cout << "Hello "; }
};
class Bar : public Foo
{
public:
virtual void bar() { cout << "World\n"; }
};
int main()
{
Bar b;
// Some kind of test to see if
// Foo::bar is implemented
b.Foo::bar();
b.bar();
return 0;
}
This isn't how you'd use this construct. If your clients, in this case
"main", depend on the behavior that bar() is implementing then there's
something wrong. The clients should only care that bar() does what the
interface advertises. Sometimes you might need to break this paradigm
(can't think of a reason, but ok) but then you'd not use virtual
functions; you would not use polymorphic types because polymorphism is
meant to allow replacing behavior.
The f() = 0 { do stuff; } construct is so that some default behavior can
be in the super that all subs can use. They call it themselves:
class Bar : public Foo
{
public:
virtual void bar() { Foo::bar(); cout << " World\n"; }
};
I have seen code resembling the following:
struct Base
{
virtual void f() { throw runtime_error("f() called in Base"); }
};
struct Derived : Base
{
};
In cases like that, any call to f() on a Derived instance will throw an
exception (and Base for that matter but there were pure virtuals
elsewhere that made this impossible).
This would sort of coincide with what the OP seems to want but it must
be stated that this is really evil. The reason why this was done is
that not all Deriveds of Base needed an f() and it didn't make sense to
call f() on them. A check was done before calling f() to see what exact
type was being used and then f() would be called. But since it was a
derived class it absolutely had to have an f() anyway.
If ever you run into a situation when Derived does not need or implement
all the behavior of Base then you've run into a situation where Derived
IS-NOT-A Base and thus you should NOT be inheriting. Too many
inexperienced (even experienced unfortunately) programmers think that
the inheritance relationship is about reuse. The inheritance
relationship is not a reuse relationship but an abstraction
relationship. The *composition* relationship is for reuse. Most often
you'll see crap like I just illustrated written by people attempting to
inherit for reuse, and not because it makes sense for a Derived to be a
Base.
Of course, once you have already decided that it DOES make sense for a
derived to be a base then you can look at common functionality and push
it up the tree. That's what the "f() = 0 { do stuff }" is for but it is
actually far from the most commonly used; more normally you'd be using
some variant of the template method.