Run-time-checking whether a pure virtual function has been implemented
Nordlöw
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
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
> 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?
>
#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
> On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> 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
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).
Noah Roberts
> On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> 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.
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
> On Aug 27, 8:58 am, Nordl�w <per.nord...@gmail.com> wrote:
>> 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?
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
> On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
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
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?
James Kanze
> mzdude wrote:
> > On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > I take to mean
> > int main()
> > {
> > Bar b;
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.)
> > b.Foo::bar();
> > b.bar();
> > return 0;
> > }
> 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.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Victor Bazarov
> On Aug 27, 8:05 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> mzdude wrote:
>>> On Aug 27, 9:04 am, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
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".
>
>>> b.Foo::bar();
>>> b.bar();
>
>>> return 0;
>>> }
>
>> 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.)
Exactly.
Juha Nieminen
> Juha Nieminen wrote:
>> Victor Bazarov wrote:
>>> 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?
>
> 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.