Function Ptrs a bad practice in c+ ?? Array od Function Ptr - Indexing issue

J

jon wayne

Hi
Am trying to replace the classic switch case construct (am workng on
a telecom stack devlpmnt)with an array of function ptrs.

The problm am facing is that of indexing. - the case vals can be
any of 0- 0xFF(1 byte long) - but unfortunately as of now I just need
to use about 15 of 'em.

In the sense I can't just make an array of function ptrs - coz the
case vals I need to use right now are high up in the range.

My soln was somethng like this

enumSomeError (*fn[])() = {NULL,NULL,... ,
decodeParamOne,NULL,...//etc};
....
// get rid of the switch
if (fn[getParamType])
fn[getParamType()};// etc

PROBLEM - since I've very few functions to be actually invoked in
the whole range, the array of function occupies quite a bit of memory -
most of which has null pointers.
Isn't there a better soln? ( I don't really want to use a Map or
any other built in c++ container)

Next , Is there really much of a performance diff betn function
pointers & switch?

Also - is the above a bad practice?? Experienced coders at my firm
say it's not a good design to use function pointers.

thanks a lot for your comments & help
 
B

benben

jon wayne said:
Hi
Am trying to replace the classic switch case construct (am workng on
a telecom stack devlpmnt)with an array of function ptrs.

The problm am facing is that of indexing. - the case vals can be
any of 0- 0xFF(1 byte long) - but unfortunately as of now I just need
to use about 15 of 'em.

In the sense I can't just make an array of function ptrs - coz the
case vals I need to use right now are high up in the range.

My soln was somethng like this

enumSomeError (*fn[])() = {NULL,NULL,... ,
decodeParamOne,NULL,...//etc};
....
// get rid of the switch
if (fn[getParamType])
fn[getParamType()};// etc

PROBLEM - since I've very few functions to be actually invoked in
the whole range, the array of function occupies quite a bit of memory -
most of which has null pointers.

That really shouts out for a map.
Isn't there a better soln? ( I don't really want to use a Map or
any other built in c++ container)

Why not? The standard container std::map isn't built in anyway. A
std::map<CaseType, boost::function<void(void)> > will get you out of a lot
of hassal while retaining the efficiency. If you are uneasy, why not tell us
why you don't want to use standard containers.

If you feel a map is slow, i would argue that a switch/case is equally slow,
dispite its appearance. Better still, if you have a large number of entries,
you can use a hash map. But my opinion is with 15 entries std::map is still
the best performing option.
Next , Is there really much of a performance diff betn function
pointers & switch?

There is, but which is better is hard to tell (and dependent on the actually
implementation and compiler). Generally, if the performance difference isn't
significant, use a more flexible design (which you can easily make
optimizations later on).
Also - is the above a bad practice?? Experienced coders at my firm
say it's not a good design to use function pointers.

What's wrong with function pointers? Be specific. I can easily see some
pitfalls with switch/case approach: it reduces modularity, it is sticky
(cannot isolate things), its rigid (cannot be easily extended), and it is
static (cannot be dynamically modified).

If you want more flexibility, try boost::function template (safer, more
flexible, easier to use)
thanks a lot for your comments & help


Why not use std::map<CaseType, boost::function<void (void)> >, assuming you
are using CaseType as case type and void(void) as handler function.
Otherwise using hashmaps is also a good idea.

Ben
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,754
Messages
2,569,528
Members
45,000
Latest member
MurrayKeync

Latest Threads

Top