Avoiding pointers to member functions

[Robert Fendt]

Hi all,

I am trying to find the best way to make part of a class's behaviour configurable during runtime, yet with as little overhead as possible. Maybe someone here has an idea? So far I have come up with 3 alternatives, all of which I do not really like for different reasons.

(1) The 'simple' solution would be to implement various alternatives of the (private) member function in question, and use a "pointer to member function" to access it. Runtime configuration can be achieved by changing the pointer value, and a function pointer should be at least as efficient as a single vtable lookup. However, I loathe function pointer syntax, and they are clumsy to use (and they IMHO hide semantics by their convoluted syntax).

(2) So, what about a functor class. It would have to be a member or friend of the outer class, and it cannot directly access the latters internals (even with 'friend' I would still have to give it a pointer to the current instance). I am also concerned about performance, since there is an additional level of indirection involved at several points when using this model.

(3) Last but not least: strict OO design, make a base class and several differently behaving child classes, and use a factory pattern to achieve at least some level of runtime flexibility. This is less flexible, so I do not really like that possibility either. Also there is the risk of duplicate code.

So, would someone please tell which obvious clear, flexible and efficient solution I am missing?

Regards,
Robert

 

[Stefan Ram]

I am trying to find the best way to make part of a class's
behaviour configurable during runtime,

I assume, you want to make the behavior of an instance
of a class to be changeable at run-time. ¯¯¯¯¯¯¯¯

The usual solution to do this, is to make the behavior
depending on some state. Then, by changing this state
(which can be done at run-time), the behavior of the
object can be adjusted.

In C++, »state« can be the state of an object, for
example of a field of the instance.

 

[BGB / cr88192]

Hi all,

I am trying to find the best way to make part of a class's behaviour
configurable during runtime, yet with as little overhead as possible.
Maybe someone here has an idea? So far I have come up with 3 alternatives,
all of which I do not really like for different reasons.

(1) The 'simple' solution would be to implement various alternatives of
the (private) member function in question, and use a "pointer to member
function" to access it. Runtime configuration can be achieved by changing
the pointer value, and a function pointer should be at least as efficient
as a single vtable lookup. However, I loathe function pointer syntax, and
they are clumsy to use (and they IMHO hide semantics by their convoluted
syntax).

1, is the most direct and also gives the best performance FWIW.

anyways, the syntax is not THAT horrible, and really, if it does seem that
bad, one can always "typedef" the function-pointer, making it look about
like a normal field...

anyways, the syntax for normal function pointers is still far less ugly than
when one is passing or returning function pointers... (maybe stop for a
second to imagine the declaration of a function accepting a function pointer
and returning another function pointer...).

(2) So, what about a functor class. It would have to be a member or friend
of the outer class, and it cannot directly access the latters internals
(even with 'friend' I would still have to give it a pointer to the current
instance). I am also concerned about performance, since there is an
additional level of indirection involved at several points when using this
model.

this depends on other factors...

if the logic involved in the methods is much larger than that of the
indirections, it is unlikely to matter so much, since, at least on x86 and
x86-64, pointer indirections are relatively cheap.

IMO, unless there is a specific reason to worry about performance
micro-issues (such as it being something likely to be done in a tight loop),
one should refrain from doing so (and instead let the profiler tell where to
optimize).

some overhead can be reduced, if possible, by grouping a number of methods
into a single class (rather than the class-per-method strategy, at which
point I would probably instead advise the function-pointer strategy...).

(3) Last but not least: strict OO design, make a base class and several
differently behaving child classes, and use a factory pattern to achieve
at least some level of runtime flexibility. This is less flexible, so I do
not really like that possibility either. Also there is the risk of
duplicate code.

2 and 3 can be combined...

So, would someone please tell which obvious clear, flexible and efficient
solution I am missing?

dunno, depends on what exactly you want...


there is always the option of using object fields and switch statements (to
re-dispatch to other methods), which has both good and bad points...

 

[Robert Fendt]

And thus spake (e-mail address removed)-berlin.de (Stefan Ram)
30 Jan 2010 19:49:50 GMT:

I assume, you want to make the behavior of an instance
of a class to be changeable at run-time. ¯¯¯¯¯¯¯¯

Yes. Sorry for being not precise on that matter. Since a class is a type and since types are not first-class entities in C++, strictly speaking one cannot change the behaviour of a class at runtime at all, always and only of its instances (this is true even for static members, which some people call 'class members').

The usual solution to do this, is to make the behavior
depending on some state. Then, by changing this state
(which can be done at run-time), the behavior of the
object can be adjusted.

I do know the concept of member variables reflecting the state of an object.. The question was more or less about what design is the best compromise between performance and elegance in order to achieve a specific kind of behaviour change. That said, and since performance really _is_ a problem in the context, there most probably is no really 'elegant' solution, and the least ugly one seems to be sticking with the member function pointer after all. Thanks anyway for taking the time, I really appreciate it.

Regards,
Robert

 

[Robert Fendt]

1, is the most direct and also gives the best performance FWIW.

anyways, the syntax is not THAT horrible, and really, if it does seem that
bad, one can always "typedef" the function-pointer, making it look about
like a normal field...

anyways, the syntax for normal function pointers is still far less ugly than
when one is passing or returning function pointers... (maybe stop for a
second to imagine the declaration of a function accepting a function pointer
and returning another function pointer...).

Yes, passing function pointers around is where the nasty really starts. Just switching stored pointers is something akin to virtual functions, in a way (just not as flexible, but more light-weight). You are right, one can use them at least in a semi-clean way, so I think I will stick with them.

there is always the option of using object fields and switch statements (to
re-dispatch to other methods), which has both good and bad points...

The switch statement pattern is of course always an option. But before I do that, I think I will stick with the member function pointer. It is a little bit faster _and_ more readable; performance really is an issue at that point, since the function in question will be run as part of an image transformation loop. So yes, I am willing to sacrifice a bit of cleanliness in the design if it yields significant speed advantages. But using switches does not look very beneficial from both the performance and the design points of view.

Regards,
Robert

 

[BGB / cr88192]

Yes, passing function pointers around is where the nasty really starts.
Just switching stored pointers is something akin to virtual functions, in
a way (just not as flexible, but more light-weight). You are right, one
can use them at least in a semi-clean way, so I think I will stick with
them.

yep.



The switch statement pattern is of course always an option. But before I
do that, I think I will stick with the member function pointer. It is a
little bit faster _and_ more readable; performance really is an issue at
that point, since the function in question will be run as part of an image
transformation loop. So yes, I am willing to sacrifice a bit of
cleanliness in the design if it yields significant speed advantages. But
using switches does not look very beneficial from both the performance and
the design points of view.

yes, agreed...

I guess some people though really like the switches though, and I guess they
do a little better in cases where there are a number of possible states, but
little liklihood of dynamically adding any new states.

 

[Marcel Müller]

Hi!

I am trying to find the best way to make part of a class's behaviour configurable during runtime, yet with as little overhead as possible. Maybe someone here has an idea? So far I have come up with 3 alternatives, all of which I do not really like for different reasons.

(1) The 'simple' solution would be to implement various alternatives of the (private) member function in question, and use a "pointer to member function" to access it. Runtime configuration can be achieved by changing the pointer value, and a function pointer should be at least as efficient as a single vtable lookup. However, I loathe function pointer syntax, and they are clumsy to use (and they IMHO hide semantics by their convoluted syntax).

Function pointers are a solution if and only if the number of possible
cases is known at the design time of your class.
Nowadays there is no much performance impact compared to switch case. If
the number of cases is larger it can be considerably faster, unless the
behavior is switched many times, because you store the (partial) result
of a decision rather than taking the decision every time anew.

(2) So, what about a functor class. It would have to be a member or friend of the outer class, and it cannot directly access the latters internals (even with 'friend' I would still have to give it a pointer to the current instance). I am also concerned about performance, since there is an additional level of indirection involved at several points when using this model.

Functors are something like user exits. They will not basically switch
functionality between a fixed number of cases. But they provide
extensibility to the user of a class instance. Of, course this is
restricted to the users permissions.

Functors have no explicit runtime overhead, since everything is done at
compile time unless you explicitly have run time code, e.g. in the
constructor. So you can control the overhead very well.
Because of this functors are often suitable in conjunction with templates.

(3) Last but not least: strict OO design, make a base class and several differently behaving child classes, and use a factory pattern to achieve at least some level of runtime flexibility. This is less flexible, so I do not really like that possibility either. Also there is the risk of duplicate code.

Inheritance is a solution if and only if the behavior of existing
objects never changes over their lifetime. The performance is comparable
to the function pointers, because the vtable calls are similar to
function pointers.

But if your behavior is constant over object lifetime there is another
solution. As cr88192 already said you can combine 2 and 3. And if you
use a template base class which takes the functors as template arguments
you will end up with no runtime overhead.

However, the same will happen with an optimizing compiler, if you pass
an enumeration type as template argument to your class to switch the
behavior and use switch/case again. If you do not like the resulting
long type names, feel free to use typedefs and end up with the same type
names as with (3). Of course, the additional restriction of limited
cases applies here.


Marcel

 

[KjellKod]

Hi all,

I am trying to find the best way to make part of a class's behaviour configurable during runtime, yet with as little overhead as possible. Maybe someone here has an idea? So far I have come up with 3 alternatives, all of which I do not really like for different reasons.

(1) The 'simple' solution would be to implement various alternatives of the (private) member function in question, and use a "pointer to member function" to access it. Runtime configuration can be achieved by changing the pointer value, and a function pointer should be at least as efficient as a single vtable lookup. However, I loathe function pointer syntax, and they are clumsy to use (and they IMHO hide semantics by their convoluted syntax).

(2) So, what about a functor class. It would have to be a member or friend of the outer class, and it cannot directly access the latters internals (even with 'friend' I would still have to give it a pointer to the current instance). I am also concerned about performance, since there is an additional level of indirection involved at several points when using this model.

(3) Last but not least: strict OO design, make a base class and several differently behaving child classes, and use a factory pattern to achieve at least some level of runtime flexibility. This is less flexible, so I do not really like that possibility either. Also there is the risk of duplicate code.

So, would someone please tell which obvious clear, flexible and efficient solution I am missing?

Regards,
Robert

Instead of functor class why not use the same functionality but
through recognized good software solutions? I'm thinking of the
different "signal and slots" implementations that are out there.
Boost, Qt (the original signal-and-slot), libsig++. Just google and
you'll find a few more.

Regards
Kjell

 

[James Kanze]

I am trying to find the best way to make part of a class's
behaviour configurable during runtime, yet with as little
overhead as possible. Maybe someone here has an idea? So far I
have come up with 3 alternatives, all of which I do not really
like for different reasons.

(1) The 'simple' solution would be to implement various
alternatives of the (private) member function in question, and
use a "pointer to member function" to access it. Runtime
configuration can be achieved by changing the pointer value,
and a function pointer should be at least as efficient as a
single vtable lookup. However, I loathe function pointer
syntax, and they are clumsy to use (and they IMHO hide
semantics by their convoluted syntax).

Also, they tend to be much less efficient than calling a virtual
function.

But the real arguments against them are those you raised, along
with the fact that you cannot associate data with them. (You
don't say what sort of configuration you're dealing with, but
it's easy to imagine configurations with parameters, e.g.
scaling or translations.)

(2) So, what about a functor class. It would have to be a
member or friend of the outer class, and it cannot directly
access the latters internals (even with 'friend' I would still
have to give it a pointer to the current instance). I am also
concerned about performance, since there is an additional
level of indirection involved at several points when using
this model.

I doubt that the performance issues will be relevant. It's a
possible solution.

(3) Last but not least: strict OO design, make a base class
and several differently behaving child classes, and use a
factory pattern to achieve at least some level of runtime
flexibility. This is less flexible, so I do not really like
that possibility either. Also there is the risk of duplicate
code.

I'm not too sure where you see the code duplication; the derived
class can always call functions in the base class for common
funtionality.

What you describe is basically the template method pattern. It
has the drawback that you can't change the configuration once
the class has been instantiated.

So, would someone please tell which obvious clear, flexible
and efficient solution I am missing?

It sounds to me that you're looking for the strategy pattern,
but it's hard to say without more details.

 

[tonydee]

yes, agreed...

I guess some people though really like the switches though, and I guess they
do a little better in cases where there are a number of possible states, but
little liklihood of dynamically adding any new states.

Actually, it's the switch/case statement that should be faster. For
calling functions with small implementations, switch statements
outperform function pointers / virtual dispatch because the optimiser
can inline the implementation and allocate registers in accord with
the cases in the switch, avoiding the more general register saving and
stack frame adjustments associated with function calls. But, profile
it and see....

Also, for performance-sensitive image processing code, you're almost
certainly much better off having a run-time switch on the outside of
the loop, then reinstantiating a template for the specific loop/
operations, gaining the benefits of full compile-time inlining and
optimisation for each operation.

Cheers,
Tony

 

[Robert Fendt]

Also, for performance-sensitive image processing code, you're almost
certainly much better off having a run-time switch on the outside of
the loop, then reinstantiating a template for the specific loop/
operations, gaining the benefits of full compile-time inlining and
optimisation for each operation.

I am doing exactly that now. The current code uses a primitive form of traits (thus static polymorphism) and is completely templated, at least as far as the fixed infrastructure goes. The test application went from 300k to 3MB, but what the heck, I don't care. For the rest (a high-level transformation function queue), there will still have to be virtual dispatch, but that just can't be helped. The especially time-consuming stuff (oversampling, interpolation etc.) will be implemented completely in templates now (so it is effectively all inlined).

Robert