Run-time-checking whether a pure virtual function has beenimplemented

[Nordlöw]

Is it possible to do runtime-checks whether a virtual base-class pure
virtual function has been implemented in an inherited class?

Thanks in advance,
Per Nordlöw

 

[Victor Bazarov]

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?

V

 

[Jonathan Lee]

Is it possible to do runtime-checks whether a virtual base-class pure
virtual function has been implemented in an inherited class?

If it compiled, it's implemented, no?

For example, the following code does not compile because "the
following virtual functions are pure within 'Derived'".

--Joathan

=======================================
#include <iostream>

class Base {
public:
virtual void print() = 0;
Base* get() { return this; }
};

class Derived : public Base {
public:
//void print() { std::cout << "Derived" << std::endl; }
void saymyname() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;

return 0;
}

 

[mzdude]

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;
}

 

[Victor Bazarov]

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

You mean there is a definition of that pure virtual function, yes?

b.Foo::bar();
b.bar();

return 0;
}

Code that calls a pure virtual function has undefined behavior. Is that
what you're trying to avoid?

There is no portable way to determine that a pure virtual function has
been implemented, AFAICT.

If you want that function called anyway, you could use 'try/catch'
around a call... How undefined behaviour translates into C++ exceptions
is defined by your implementation (if at all).

V

 

[Noah Roberts]

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.

 

[Victor Bazarov]

If it compiled, it's implemented, no?

No. Using the scope resolution you can explicitly call a pure function
even for the derived class that has a non-pure final overrider. See
elsethread.

For example, the following code does not compile because "the
following virtual functions are pure within 'Derived'".

--Joathan

=======================================
#include <iostream>

class Base {
public:
virtual void print() = 0;
Base* get() { return this; }
};

class Derived : public Base {
public:
//void print() { std::cout << "Derived" << std::endl; }
void saymyname() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;

return 0;
}

V

 

[Noah Roberts]

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;
}

ok, maybe I misunderstood what you were illustrating. Anyway, I think
my comment might still be useful to the OP. I'm having trouble deciding
what they want answered.

 

[mzdude]

mzdude wrote:

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.

I know. I was trying to provide a simple example. You went on
to provide a better one. Thanks.

 

[Juha Nieminen]

Code that calls a pure virtual function has undefined behavior.

What do you mean? Why would you be able to write an implementation for
a pure virtual function if calling it was UB?

 

[Victor Bazarov]

What do you mean? Why would you be able to write an implementation for
a pure virtual function if calling it was UB?

I mean if it has no implementation. Right after this I asked if that
was what OP was trying to avoid. If it has implementation, there is no
problem, if it doesn't, the results are undefined. Do I have to spell
everything?

V

 

[James Kanze]

You mean there is a definition of that pure virtual function,
yes?

I'm not too sure what he is asking, but I don't think it has
anything to do with this---he did say "implemented in an
inherited class". (Of course, taken literally, the answer is
simple: there's no runtime check, because if it isn't
implemented in a derived class, you can't instantiate objects of
that type.)

Code that calls a pure virtual function has undefined
behavior.

No. Code that would resolve dynamically to a pure virtual
function is undefined behavior, but code that doesn't use
dynamic resolution can use it.

Is that what you're trying to avoid?

There is no portable way to determine that a pure virtual
function has been implemented, AFAICT.

It has been implemented. Otherwise, you can't instantiate
objects of the type. If the inheritance hierarchy is more than
two levels, however, there's no way to know whether it was
instantiated in the most derived class, or in one of the
intermediate classes. (Maybe that's what he's asking. Maybe
not.)

 

[Victor Bazarov]

I'm not too sure what he is asking, but I don't think it has
anything to do with this---he did say "implemented in an
inherited class". (Of course, taken literally, the answer is
simple: there's no runtime check, because if it isn't
implemented in a derived class, you can't instantiate objects of
that type.)

But you can, as subobjects of the some other derived class.
Theoretically, I still might want to check if the "child" has
implemented some pure virtual function or not, which would mean that the
function is defined in some "[great-]grandchild".

No. Code that would resolve dynamically to a pure virtual
function is undefined behavior, but code that doesn't use
dynamic resolution can use it.



It has been implemented. Otherwise, you can't instantiate
objects of the type. If the inheritance hierarchy is more than
two levels, however, there's no way to know whether it was
instantiated in the most derived class, or in one of the
intermediate classes. (Maybe that's what he's asking. Maybe
not.)

Exactly.

V

 

[Juha Nieminen]

I mean if it has no implementation. Right after this I asked if that
was what OP was trying to avoid. If it has implementation, there is no
problem, if it doesn't, the results are undefined. Do I have to spell
everything?

You were responding to a post where there was a pure virtual function
with an implementation. Thus it sounded like you were saying that
calling it is UB.