avoid polymorphism

[Guest]

I have class:
------------
class Component {
void setEnabled(bool state);
}
------------
I want "setEnabled" don't be virtual (there are many member functions. not virtual for efficient).
If a derived class "Button" does polymorhism in "setEnabled" then in this function:
------------
void func(Component &a) {
a.setEnabled(true);
}
------------
will not be called "Button.setEnabled" but "Component.setEnabled" (because "setEnabled" is not virtual)

So, Because I create a library and I want to be far from these quiet errors
I ask:
Is there a trick to avoid polymorphism in this member function???

Thanks!

 

[Howard]

I have class:
------------
class Component {
void setEnabled(bool state);
}
------------
I want "setEnabled" don't be virtual (there are many member functions. not virtual for efficient).
If a derived class "Button" does polymorhism in "setEnabled" then in this function:
------------
void func(Component &a) {
a.setEnabled(true);
}
------------
will not be called "Button.setEnabled" but "Component.setEnabled" (because "setEnabled" is not virtual)

So, Because I create a library and I want to be far from these quiet errors
I ask:
Is there a trick to avoid polymorphism in this member function???

Thanks!

I don't understand why you do not want setEnabled to be virtual...? If you
want to be able to call the correct setEnabled via a base class reference,
then it HAS to be virtual! That's the whole purpose of a virtual function.
It has to be one way or the other: either the function overrides a virtual
base class function and you can then call the correct version via a base
class pointer or reference, or else the function hides the base class
function and you have to have an a pointer or reference to the actual
derived class in order to call the derived class' function.

-Howard

 

[jeffc]

I have class:
------------
class Component {
void setEnabled(bool state);
}
------------
I want "setEnabled" don't be virtual (there are many member functions. not virtual for efficient).
If a derived class "Button" does polymorhism in "setEnabled" then in this function:
------------
void func(Component &a) {
a.setEnabled(true);
}
------------
will not be called "Button.setEnabled" but "Component.setEnabled" (because "setEnabled" is not virtual)

So, Because I create a library and I want to be far from these quiet errors
I ask:
Is there a trick to avoid polymorphism in this member function???

I understand that English is not your first language, but still your
question is very confusing. You are certainly avoiding polymorphism if you
don't use virtual functions. What you want is not clear.

 

[Kevin Saff]

So, Because I create a library and I want to be far from these quiet errors
I ask:
Is there a trick to avoid polymorphism in this member function???

Any "trick" you come up with is likely to take as long as doing a virtual
lookup anyway. So, you aren't gaining much by avoiding "virtual" except
making your code harder to understand.

 

[Noah Roberts]

Any "trick" you come up with is likely to take as long as doing a virtual
lookup anyway. So, you aren't gaining much by avoiding "virtual" except
making your code harder to understand.

Just how heavy is a lookup anyway? I know that in Objective-C it is
*very* heavy (takes a good chunk of the running time) but in that
language it shows up in a profile as an actual function call. How is it
done in C++ and what resources is it likely to consume?

NR

 

[Karl Heinz Buchegger]

Just how heavy is a lookup anyway? I know that in Objective-C it is
*very* heavy (takes a good chunk of the running time) but in that
language it shows up in a profile as an actual function call. How is it
done in C++ and what resources is it likely to consume?

Usually virtual functions are implemented by having a lookup table associated
with that class (the so called VTable)
If the compiler needs to compile a virtual function call he implements code
to:

use the 'this' pointer of the object to locate the VTable.
offset into the VTable to locate the starting address of the function
Use the address found in the VTable to make the call

So basically it boils down to one memory fetch and an indirect function
call, instead of a direct call.
All in all not much overhead, compared to anything else you could come
up with to implement the same functionality.

If you need polymorphism, you need polymorphism. And the compilers way
to implement it, is probably the best one can get.

 

[Karl Heinz Buchegger]

Usually virtual functions are implemented by having a lookup table associated
with that class (the so called VTable)
If the compiler needs to compile a virtual function call he implements code
to:

use the 'this' pointer of the object to locate the VTable.
offset into the VTable to locate the starting address of the function
Use the address found in the VTable to make the call

So basically it boils down to one memory fetch and an indirect function

Sorry: two memory fetches.
First: the object carries a pointer to the vtable, get that
second: use the pointer from 1, add offset and fetch the functions start address

 

[Dietmar Kuehl]

Sorry: two memory fetches.

Well, the expensive part is the indirect function anyway: if things are
OK, the data will be in the cache and thus the access would be likely to
cost an extra memory cycle. The indirection function on the other hand
is quite costly because it cannot be inlined. Not inlining of functions
in performance critical sections has two separate costs:

- There is some function call setup normally necessary which takes a bunch
of cycles and forces data to be stored in particular registers or memory
locations when parameters or returns are passed around.
- The units for optimization are chopped into smaller pieces, reducing the
effectivity of the optimizer.

Of course, unless profiling indicates that the function is indeed in a
critical section, both aspects are effectively moot: the function should
not be inlined in this case anyway because compilation dependencies are
best avoided unless there are good reasons to accept them.

 

[Guest]

Any "trick" you come up with is likely to take as long as doing a virtual

lookup anyway. So, you aren't gaining much by avoiding "virtual" except
making your code harder to understand.

I have almost 60 member functions in class Component.
If all of these are virtual, efficient will decreased

 

[jeffc]

I have almost 60 member functions in class Component.
If all of these are virtual, efficient will decreased

Actually, if any one of them are virtual, efficiency will be decreased.
Having said that, unless you're coding real-time systems for the space
shuttle T-1 launch sequence, or looping millions of times through nested
function calls for large database transactions, or writing the chess program
to beat Garry Kasparov, it's really not going to make any difference. I
think we need some perspective here.

 

[=?iso-8859-1?Q?Juli=E1n?= Albo]

I have almost 60 member functions in class Component.
If all of these are virtual, efficient will decreased

If the program does not work as desired, efficiency will be 0.

And probably you don't need yo make all them virtual. It's not an all or
nothing election.

Regards.

 

[Adam H. Peterson]

Actually, if any one of them are virtual, efficiency will be decreased.
Having said that, unless you're coding real-time systems for the space
shuttle T-1 launch sequence, or looping millions of times through nested
function calls for large database transactions, or writing the chess program
to beat Garry Kasparov, it's really not going to make any difference. I
think we need some perspective here.

More to the point, the virtual mechanism in C++ is almost invariably
going to be faster than anything people will typically code instead to
do the same job. If it's polymorphic behavior you want and need,
virtual functions are almost always the tool for the job, even where
efficiency is concerned.

Just my $0.02

Adam H. Peterson

 

[Icosahedron]

If the program does not work as desired, efficiency will be 0.

And probably you don't need yo make all them virtual. It's not an all or
nothing election.

Regards.

You might be able to use templates. I'm a little rusty on them
myself, but something like

template <typename T>
bool func(T& a)
{
a.setEnabled(false);
}

This will give you a compiler error if setEnabled is not on the type
T.

This wasn't run through a compiler, but something like that should
work.

Jay