Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382646

Re: Function Pointers...

Show all headers | View raw

porkchop@invalid.foo (Mike Sanders) writes:

> For a good while I've been wanting to use function pointers
> & I finally found an opportunity to do so...
>
> Currently I have:
>
> switch(ops.export) {
>     case 1: outputTXT(p, nodes, c); break;
>     case 2: outputCSV(p, nodes, c); break;
>     case 3: outputSQL(p, nodes, c); break;
>     case 4: outputHTM(p, nodes, c); break;
> }
>
> But instead I could use:
>
> void (*output[])(FILE*, BLOCK[], int) =
>     { outputTXT, outputCSV, outputSQL, outputHTM };
>
> // do stuff
>
> output[ops.export -1](p, nodes, c);
>
> Now here's where I'm unsure:  Perhaps the overhead of an indirect
> call is miniscule, even negligible.  But there *IS* additional
> overhead when using function pointers correct?

Let me give the conclusion first and the explanation second.

Conclusion:  if you think the array-of-function-pointers approach
looks better or improves program structure then by all means use
it.

Explanation:  I got interested in this question some years ago,
in a similar scenario.  Calling through a pointer-to-function can
and sometimes does incur a performance penalty compared to
calling a function directly.  What I was interested in though is
a comparison like the one you are interested in:  should I use
a switch() with direct calls, or indirect calls using an array of
function pointers.  So I did some measurements.  The results were
very nearly the same for the two different schemes.  Choosing one
approach over the other was a wash, performance-wise.  I didn't
do an exhaustive study or anything like that, but the results I
did get showed that, at least to first order, there is no speed
preference for either choice.  So pick the one that gives a more
nicely structured program, and don't worry about which one might
be faster.

(Later on you might want to do some measurements and actually see
which approach runs faster, but the evidence suggests there is no
reason to worry about that now.)

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 21:16 +0000
  Re: Function Pointers... scott@slp53.sl.home (Scott Lurndal) - 2024-02-17 21:23 +0000
    Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 21:48 +0000
      Re: Function Pointers... scott@slp53.sl.home (Scott Lurndal) - 2024-02-17 22:26 +0000
        Re: Function Pointers... "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-17 14:31 -0800
        Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 23:41 +0000
  Re: Function Pointers... bart <bc@freeuk.com> - 2024-02-17 21:32 +0000
    Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 21:55 +0000
      Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 22:07 +0000
  Re: Function Pointers... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-17 21:59 +0000
    Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 23:36 +0000
  Re: Function Pointers... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-17 21:59 +0000
    Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-17 23:38 +0000
      Re: Function Pointers... Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-17 23:59 +0000
  Re: Function Pointers... Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-17 16:47 -0800
    Re: Function Pointers... porkchop@invalid.foo (Mike Sanders) - 2024-02-18 11:26 +0000
      Re: Function Pointers... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-18 11:52 +0000
        Re: Function Pointers... bart <bc@freeuk.com> - 2024-02-18 12:59 +0000
  Re: Function Pointers... David Brown <david.brown@hesbynett.no> - 2024-02-18 14:41 +0100
    Re: Function Pointers... bart <bc@freeuk.com> - 2024-02-18 14:29 +0000

csiph-web