Here''s my current situation. I have a large switch statement, with special case code for most of the cases. As far as I know, this isn''t very efficient because (for instance) if the case I''m looking for is the last case in the large switch statement, then my program will test every one of the previous cases before it gets to the last case statement. What I was thinking about was having an array of function pointers, and have the thing that was being tested in the case statement be an index into the array of function pointers, then call the appropriate function immediately, saving the work of essentially doing a linear search for the correct code in the large switch statement. The data being tested in the case statements is simply 1, 2, 3, 4, and so on, so I would use all but index 0 into the function pointer array. For some reason, I''m not sure if this will work, or if it will be more efficient. It makes sense that it would be more efficient, but it seems like I heard somewhere along the way that this won''t work for some reason. I don''t see why it shouldn''t though. Has anyone tried something like this? Will it work? More efficiently? Thanks, Russell

It will work, but any good optimising compiler will compile your switch statement similar to what you are trying to implement with your function pointers, compile both and compare the assembly.

An array of function pointers all have to be the same type; as in they all have the same arguments and return type. I don't think you can use variable arguments either, though I could be wrong.

Also, I think it's more important to produce readable code. A switch statement is going to make more sense in 3 months, where an array of function pointers isn't. The difference between the switch and the array lookup is going to be negligible. You'll save more time optimizing your algorithm.


[edited by - cgoat on June 24, 2002 5:31:58 PM]

I agree. Besides, even if the compiler wouldn''t optimize this it''s not likely this would be your bottle neck.

The way to get got performance is to write good algorithms in the first place. Then, profile your code and see where you have bottlenecks. Optimize those, rather than randomly picking pieces in the code to be optimized.

quote:Original post by Russell
As far as I know, this isn''t very efficient because (for instance) if the case I''m looking for is the last case in the large switch statement, then my program will test every one of the previous cases before it gets to the last case statement.

Nope. Switch statements are most commonly converted into jump tables, though you can gain infinitesimally by placing your case labels in order of decreasing frequency of occurence.

Which, as you should have guessed, is a worthless optimization. Just write the code.

quote:Besides, even if the compiler wouldn''t optimize this it''s not likely this would be your bottle neck.

You don''t know what the switch statement does, so you can''t assume that it is or is not a bottleneck. I had this exact situation a few weeks ago when I was writing a videogame emulator and needed an efficient way to branch off to the CPU instruction code (512 opcodes), so in my case it was a critical part of the program.

My conclusion was: With VC++ Standard Edition (it can''t do optimizations), the switch version was about 10% faster than the function pointer array version. I assume with Professional or Enterprise Edition, it would optimize the switch a bit for maybe 15-20% faster overall?

BTW what is this code doing, Russell?

Move generation for my chess program.

It is possible to have an array of function pointers with different return types as well as variable arguments. I''ve done it in an optimization program where the set of functions to be called was determined dynamically.

quote:Original post by cgoat
An array of function pointers all have to be the same type; as in they all have the same arguments and return type. I don''t think you can use variable arguments either, though I could be wrong.

quote:Original post by nemethr
It is possible to have an array of function pointers with different return types as well as variable arguments.

Maybe as a vendor-provided extension, but not using Standard C or C++ it''s not. The return type and all arguments contribute to the function type, and you cannot have a heterogeneous array in C or C++.

I stand corrected. I'll blame my rusty memory. When I glanced at the code I mentioned, I saw that I had functions with varying return types/parameters. I forgot that NOT ALL of these functions are included in the function pointer array. You were absolutely right, the functions that ARE included have the same return type and argument list.

However, you CAN use a variable argument list (like printf) to achieve the effect of functions with differing arguments.

Sorry for jumping the gun.

quote:Original post by SabreMan
Maybe as a vendor-provided extension, but not using Standard C or C++ it's not. The return type and all arguments contribute to the function type, and you cannot have a heterogeneous array in C or C++.

[edited by - nemethr on June 25, 2002 12:56:31 PM]

[edited by - nemethr on June 25, 2002 1:29:13 PM]