Help structuring my program (arrays of function pointers/ passing variables to functions)

[googlinggoogler]

Hi

This should all be pretty standard C stuff, but I'm going to use terms
like mouse callback to communicate what Im tyring to do.

Basically I have my program whirling around in an infinite loop (easy)
waiting for the mouse to be clicked (I dont need help with this) and
depending on user input a variable might define what function I want
(be it line, circle....(again these are my issues)

So I was thinking that I could use something like an array of function
pointers because I can make all the functions exist with the same
function type I suppose, although that could potentially get messy

What I dont know how to do neatly (I could bodge something but im
trying to do this properly) is essentially have something as follows

1) inside loop some case statement where I can set some varible to
state i want to call the line, circle, etc (theres loads of these)
function. (all these functions in some array of function prototypes
somewhere?)

2)pass the number of mouse clicks to wait to some global variable that
can be picked up when I hit the mouse.

3) in same said mouse call back, use the variable set in point 1 to
get some function pointer someplace from some array of function
pointers and then call something like function_circle(int x, int y,
char color, char text) based on what i've set previously...

I can see lots of holes in this and was woundering whether someone
could help me with my ideas?

Regards

David

 

[Nick Keighley]

This should all be pretty standard C stuff, but I'm going to use terms
like mouse callback to communicate what Im tyring to do.

I think that's where your problem originates.
Yes you have a C program design problem. But you also have
a GUI implementation problem and maybe a UI design problem.

For general programming try comp.programming. For UI design-
I dunno.

Are you designing all this from scratch (brave man!) or are you using
an existing GUI framework? If the 2nd then there's probably an
existing
framework.

Basically I have my program whirling around in an infinite loop (easy)
waiting for the mouse to be clicked (I dont need help with this) and
depending on user input a variable might define what function I want
(be it line, circle....(again these are my issues)

So I was thinking that I could use something like an array of function
pointers because I can make all the functions exist with the same
function type I suppose, although that could potentially get messy

could do...

maybe:-

for (;
{
if (mouse_clicked)
{
if (using_tool)
draw[tool](mouse_posn); /* array of func ptr */
else
do_button_processing(); /* may select new tool */
}
}

I think you need to decide how your GUI is going to work.

 

[santosh]

Hi

This should all be pretty standard C stuff, but I'm going to
use terms like mouse callback to communicate what Im tyring to
do.

Basically I have my program whirling around in an infinite loop
(easy) waiting for the mouse to be clicked (I dont need help
with this) and depending on user input a variable might define
what function I want (be it line, circle....(again these are my
issues)

So I was thinking that I could use something like an array of
function pointers because I can make all the functions exist
with the same function type I suppose, although that could
potentially get messy

Don't force different function pointer types to one type. It'll
most likely lead to undefined behaviour.

What I dont know how to do neatly (I could bodge something but
im trying to do this properly) is essentially have something as
follows

1) inside loop some case statement where I can set some varible
to state i want to call the line, circle, etc (theres loads of
these) function. (all these functions in some array of function
prototypes somewhere?)

Array of function prototypes? There's no such thing. If you mean
an array of function pointers, then I suppose all the functions
have the same return type and parameter list?

2)pass the number of mouse clicks to wait to some global
variable that can be picked up when I hit the mouse.

3) in same said mouse call back, use the variable set in point
1 to get some function pointer someplace from some array of
function pointers and then call something like
function_circle(int x, int y, char color, char text) based on
what i've set previously...

Basically, I think we can ignore the mouse issue. To be brief,
your program waits for some input, (what is the type and format
of this input?), then picks a particular function pointer out of
an array of function pointers and deferences it.

I think the input receiving part, and function pointer retrieval
part should be in separate functions. The function pointer array
itself could be a global array. A switch statement could could
decide on the array subscript, or, if the choices are more
complex, an else-if construct could be used.

I can see lots of holes in this and was woundering whether
someone could help me with my ideas?

Without knowing more details about the structure and function of
your program, we cant give anything other than the most general
advice.

 

[Eric Sosman]

Don't force different function pointer types to one type. It'll
most likely lead to undefined behaviour.

Just to be clear: santosh is thinking about the likelihood
of making mistakes later on, not about the conversion of the
function pointer itself. Any function pointer type can be
converted to any other function pointer type and back again
without damage; this is an explicit guarantee of the language.
However, it *is* undefined behavior if you call a function via
a pointer whose type doesn't match the function's actual type:

#include <math.h>
double (*fptr1)(double) = sqrt; /* okay */
int (*fptr2)(int) = (int (*)(int))sqrt; /* okay */
...
double x = fptr1(2); /* okay */
double y = fptr2(2); /* undefined behavior */

By using appropriate casts, you can fill your array with
pointers to any functions of any type at all, but you *must*
convert the pointer back to the proper type when calling:

y = ((double (*)(double))fptr2)(2); /* okay */

(A few typedefs can improve the readability quite a lot.)
Fail to convert when needed, or convert to the wrong type,
and you're toast.