Why functions pointers

There's load of reasons todo it, if we take your glClear as an example if you move it to an application defined function pointer like qglClear and you get a lot of flexibility.

You can with very little work do the following:

* disable clearing without changing any code
* count the number of calls
* implement workarounds for known buggy drivers
...


see, and all it really cost you is one extra indirection hardly nothing.

Quake uses them extensively because that way they were able to switch quickly from their original software rendering to the OGL renderer (and, presumably, to Glide, or D3D, or whatever else they wanted).

Obviously that's not so important when using C++, since you can just encapsulate all that within a class, but it's invaluable under C.

Quote:

Original post by DigitalDelusion There's load of reasons todo it, if we take your glClear as an example if you move it to an application defined function pointer like qglClear and you get a lot of flexibility. You can with very little work do the following: * disable clearing without changing any code * count the number of calls * implement workarounds for known buggy drivers ... see, and all it really cost you is one extra indirection hardly nothing.

How could you disable the function without changing code

You can't, but you could point the function pointer at a function that does nothing.

Assuming your scripting system allows access to variable values and functions, you'd just re-assign the qglClear() function pointer to point at a no-op function, rather than pointing at glClear.

he meant without changing the CALLING code all through the program ...

and almost any program that supports such things, read which function pointer to assign during initialization from a config file ... therefor you can choose to use software rendering, GL rendering, etc ... all in your config file (or even anytime you want if you temporarily disable the rendering loop, reassign the function pointers, then reenable the loop).

I think I get it.

Lets say for some reason the target system does not support glClear function.
The code could just switch to a clearing function created by the programmer by just pointing to the new function.And changing the function that called the clearing function would be needed.

I am right?

Yup.

Here's one way I use fp's in my own code:

To get rid of huge 'switch' statements that would've been executed each frame...

each(frame){  switch (lighting_model)  {  case none:    render_unlit_function();    break;  case simple:    ...  case multiple:    ...  case simple_shadow:    ...  }}

Now the whole thing with fp's:

each(frame){  render_fp();   }//outside main loopon_user_change_lighting_model(...){  switch(...)  {    case none:      render_fp = render_unlit_function();    case simple:      render_fp = render_simple_function();  }}

I think it makes the main loop a bit easier to read, and the overhead introduced by fp's should be way less then the overhead of nested 'if, else' or 'switch' statements.

edit: thanks for confirming that DigitalDelusion I was too tired to confirm my claim via reference (almost midnight here...), and I've been at work for about 12 hours+.

[Edited by - Wildfire on July 2, 2004 4:13:24 PM]

The function pointer approach is way faster than nested ifs or switch statements, all it takes is one extra pointer indirection the cost of that is less than checking one conditional (execluding the actual branching here).

They're an extremly usefull tool in much the same way as working with classes containging virtual functions are just at a lower level.