Ah've got them Function Pointer blues

[MikeC]

Folks,

I've been playing with C programs for 25 years (not professionally -
self-taught), and although I've used function pointers before, I've never
got my head around them enough to be able to think my way through what I
want to do now. I don't know why - I'm fine with most other aspects of the
language, but my brain goes numb when I'm reading about function pointers!

I would like to have an array of structures, something like

struct FS
{ <function pointer>;
<some other variables>;
};

My problem is that the <function pointeris of unknown type - in
function_struct ure[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) {....}

etc.

I would like to initialise the array directly, like
struct FS function_struct ure[] = {{ ....}, {....}, ...., {....}};

.... but I'm really shaky on what to put in those braces. I have been
playing with it, but so far unsuccessfully.

Is it possible? How do I declare the pointer in the structure, and how do I
assign a pointer value to it? And when I call it, how do I pass arguments
from the program? Could somebody give me a very simple example?

This isn't a homework thing, by the way - I write mostly little programs
that get used at work by colleagues. It improves my street-cred
(geek-cred? - well, no - I've just blown that notion!).

Incidentally, this may not be the best way to design the program, so I'd
like to ask about that too.
Can anybody suggest a newsgroup? (program architecture isn't really C)

Thanks,

MikeC
--
Mental decryption required to bamboozle spam robots:

mijewen$btconne ct*com
$ = @
* = dot

[Ben Bacarisse]

"MikeC" <Mi*******@btco nnect.comwrites :

<snip>

I would like to have an array of structures, something like

struct FS
{ <function pointer>;
<some other variables>;
};

My problem is that the <function pointeris of unknown type - in
function_struct ure[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) {....}

etc.

That is not a problem since a function pointer of one type can be
converted to a function pointer of another type. The simplest is to
pick either a generic function pointer type and use that (the type
void (*)() is often used for this) or to pick the most common, thereby
cutting down the number of conversions needed.

Note that you need to convert the pointer to the right type at the
point of call.

I would like to initialise the array directly, like
struct FS function_struct ure[] = {{ ....}, {....}, ...., {....}};

Well, using the idea of a bland generic function pointer and using
typedefs to make the syntax simple:

typedef void function();

The struct will the look like this:

struct FS {
function *fp;
/* other data */
};

and you set up an array of them like this:

struct FS function_struct ure[] = {
{(function *)func_1, /* other data */},
{(function *)func_2, /* other data */}
};

The function call is horrible, though. function_struct ure[1].fp is of
type 'function *' and must be converted to 'void (*)(char **)' so you
need to write:

((void (*)(char **))function_st ructure[1].fp)(argv);

... but I'm really shaky on what to put in those braces. I have been
playing with it, but so far unsuccessfully.

You can simplify the casts with typedefs for you common pointer types
if you like.

Is it possible? How do I declare the pointer in the structure, and how do I
assign a pointer value to it? And when I call it, how do I pass arguments
from the program? Could somebody give me a very simple example?

--
Ben.

[voidpointer]

On 20 ago, 20:14, "MikeC" <Mike.B...@btco nnect.comwrote:

Folks,

I've been playing with C programs for 25 years (not professionally -
self-taught), and although I've used function pointers before, I've never
got my head around them enough to be able to think my way through what I
want to do now. *I don't know why - I'm fine with most other aspects ofthe
language, but my brain goes numb when I'm reading about function pointers!

I would like to have an array of structures, something like

struct FS
{ <function pointer>;
* *<some other variables>;

};

My problem is that the <function pointeris of unknown type - in
function_struct ure[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) *{....}

etc.

I would like to initialise the array directly, like
*struct FS *function_struc ture[] = {{ ....}, {....}, ...., {....}};

... but I'm really shaky on what to put in those braces. *I have been
playing with it, but so far unsuccessfully.

Is it possible? *How do I declare the pointer in the structure, and howdo I
assign a pointer value to it? *And when I call it, how do I pass arguments
from the program? *Could somebody give me a very simple example?

This isn't a homework thing, by the way - I write mostly little programs
that get used at work by colleagues. *It improves my street-cred
(geek-cred? - well, no - I've just blown that notion!).

Incidentally, this may not be the best way to design the program, so I'd
like to ask about that too.
Can anybody suggest a newsgroup? (program architecture isn't really C)

Thanks,

MikeC

--
Mental decryption required to bamboozle spam robots:

mijewen$btconne ct*com
$ = @
* = dot

as Ben Becarisse said, do make your code more readable use the
typedef,

/* funcPtr is a pointer function that has two int
as argument, and return int */
typedef int (*funcPtr)(int, int);

now in your structure

struct your_struct {
funcPtr func;
};

now to initialize your structure

struct your_function t[] = {
{&anyfunction /* with the same type of funcPtr */ },
{ /* here more declarations */ }
};

now to use

(t[0].func)(argument _1, argument_2);

a more complete example

------ start ------
#include <stdio.h>

typedef int (*funcPtr)(int, int);

struct test {
funcPtr func;
int a, b;
};

int print_sum(int a, int b)
{
printf("%d\n", a + b);
return a + b;
}

int main(void) {
struct test t[] = {
{&print_sum, 2, 2},
{&print_sum, 5, 5}
};

(*(t[0].func))(t[0].a, t[0].b);
(t[1].func)(t[1].a, t[1].b);
/* the two ways is valid, but the second is more preferred
and is supported since of c89 standard */
return 0;
}
------- end --------

[Ben Bacarisse]

voidpointer <di************ @gmail.comwrite s:

On 20 ago, 20:14, "MikeC" <Mike.B...@btco nnect.comwrote:

>I would like to have an array of structures, something like

struct FS
{ <function pointer>;
Â* Â*<some other variables>;

};

My problem is that the <function pointeris of unknown type - in
function_struc ture[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) Â*{....}

etc.

<snip>

>MikeC

--
Mental decryption required to bamboozle spam robots:

mijewen$btconn ect*com
$ = @
* = dot

Best not to quote sig block (unless you are commenting on them)

as Ben Becarisse said, do make your code more readable use the
typedef,

/* funcPtr is a pointer function that has two int
as argument, and return int */
typedef int (*funcPtr)(int, int);

I prefer to not hide the pointer in the typedef. I can see you agree
because you felt the need to reveal the pointerness in the name. "*" is
shorter that "Ptr" and...

now in your structure

struct your_struct {
funcPtr func;

function *func;

Is just as easy to read (for someone who has had to "get" pointers).

It is a small point (and by no means universally agreed upon) but it
seems worth noting. It has the huge benefit that you can avoid a lot
of the (*name)(...) syntax that seems to be the stumbling block for so
many people.

};

now to initialize your structure

struct your_function t[] = {
{&anyfunction /* with the same type of funcPtr */ },
{ /* here more declarations */ }
};

now to use

(t[0].func)(argument _1, argument_2);

The OP was interested in there being different function types. You
got to show the neat version!

a more complete example

------ start ------
#include <stdio.h>

typedef int (*funcPtr)(int, int);

struct test {
funcPtr func;
int a, b;
};

int print_sum(int a, int b)
{
printf("%d\n", a + b);
return a + b;
}

int main(void) {
struct test t[] = {
{&print_sum, 2, 2},
{&print_sum, 5, 5}
};

(*(t[0].func))(t[0].a, t[0].b);
(t[1].func)(t[1].a, t[1].b);
/* the two ways is valid, but the second is more preferred
and is supported since of c89 standard */

I prefer t[1].func(t[1].a, t[1].b); because I don't like extra
parentheses, but that is also debatable.

return 0;
}
------- end --------

--
Ben.

[MikeC]

Gentlefolk,

You're good people. Your time and attention are very much appreciated.

Reading through it, it all makes sense - though I still have to work it into
operation.
I think the problem that I have (and maybe other people have) is that if you
have a pointer to a variable (of whatever type), and you execute

*foo = bar

you can easily see the mechanism of what happens. You'll laugh at the
analogy, but to me, it's like the postman handing the value to the variable
directly through the front door, but when it's a function pointer, the
postman comes to the door, gets on his mobile phone, and tells somebody else
to take the arguments around to the back door. They don't get to the
function by the same mechanism that gets a value to a dereferenced variable.

What I have learned, or at least had my eyes opened to from your
instructions, is that you can make a cast to a function pointer. I never
thought of that before, and I don't think I've read about it. Well, maybe I
did, but my brain was numb.

Thanks again for freely sharing your expertise.

MikeC

"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..

voidpointer <di************ @gmail.comwrite s:

>On 20 ago, 20:14, "MikeC" <Mike.B...@btco nnect.comwrote:

>>I would like to have an array of structures, something like

struct FS
{ <function pointer>;
<some other variables>;

};

My problem is that the <function pointeris of unknown type - in
function_stru cture[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) {....}

etc.

<snip>

>>MikeC

--
Mental decryption required to bamboozle spam robots:

mijewen$btcon nect*com
$ = @
* = dot

Best not to quote sig block (unless you are commenting on them)

>as Ben Becarisse said, do make your code more readable use the
typedef,

/* funcPtr is a pointer function that has two int
as argument, and return int */
typedef int (*funcPtr)(int, int);

I prefer to not hide the pointer in the typedef. I can see you agree
because you felt the need to reveal the pointerness in the name. "*" is
shorter that "Ptr" and...

>now in your structure

struct your_struct {
funcPtr func;

function *func;

Is just as easy to read (for someone who has had to "get" pointers).

It is a small point (and by no means universally agreed upon) but it
seems worth noting. It has the huge benefit that you can avoid a lot
of the (*name)(...) syntax that seems to be the stumbling block for so
many people.

>};

now to initialize your structure

struct your_function t[] = {
{&anyfunction /* with the same type of funcPtr */ },
{ /* here more declarations */ }
};

now to use

(t[0].func)(argument _1, argument_2);

The OP was interested in there being different function types. You
got to show the neat version!

>a more complete example

------ start ------
#include <stdio.h>

typedef int (*funcPtr)(int, int);

struct test {
funcPtr func;
int a, b;
};

int print_sum(int a, int b)
{
printf("%d\n ", a + b);
return a + b;
}

int main(void) {
struct test t[] = {
{&print_sum, 2, 2},
{&print_sum, 5, 5}
};

(*(t[0].func))(t[0].a, t[0].b);
(t[1].func)(t[1].a, t[1].b);
/* the two ways is valid, but the second is more preferred
and is supported since of c89 standard */

I prefer t[1].func(t[1].a, t[1].b); because I don't like extra
parentheses, but that is also debatable.

>return 0;
}
------- end --------

--
Ben.

[August Karlstrom]

MikeC wrote:
[...]

I would like to have an array of structures, something like

struct FS
{ <function pointer>;
<some other variables>;
};

My problem is that the <function pointeris of unknown type - in
function_struct ure[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) {....}

etc.

How come the functions have different signature and what do you want to
achieve? Please, tell us a bit more about the underlying problem.
August

[MikeC]

"August Karlstrom" <fu********@com hem.sewrote in message
news:g8******** **@aioe.org...

MikeC wrote:
[...]

>I would like to have an array of structures, something like

struct FS
{ <function pointer>;
<some other variables>;
};

My problem is that the <function pointeris of unknown type - in
function_struc ture[2] it may be

int func_1(int, int) {....}

in function_struct ure[5], it may be

void func_2(char **cpt) {....}

etc.

How come the functions have different signature and what do you want to
achieve? Please, tell us a bit more about the underlying problem.
August

Well, I would have done that in the first place, but that's to do with
architecture, not with C, and this is a C group, and flames burn me. In my
original post, I asked:

"Incidental ly, this may not be the best way to design the program, so I'd
like to ask about that too.
Can anybody suggest a newsgroup? (program architecture isn't really C)"

However, as you ask ...

I haven't finished specifying the program yet - I keep having bigger and
better ideas - but I want to write a text macro engine. It will interpret
commands from a (text) command file, executing them on an input (read only)
file, and producing an output file. The commands will be, for example

copy off // don't copy anythying from the input file to the output file
find_forward "a text string"
move_left 6 // characters
copy on // this causes any character scanned by the cursor to be copied to
the output file
loop 6 // times
{ <more commands>
}
etc....

.... you get the idea.
I wanted to run through the command (program) file and compile it into a
forth-like stack (yes, I'm a dinosaur), with each stack element being a
structure, which contains, among other things, a pointer to the function
that will execute the command. The commands do different things, so they
have different signatures, hence my question.

Among all the ways of solving this problem (the architecture problem), I'm
sure people who have spent a life in preofeesional programming will know of
much better methods, and probably be able to pull in other
packages/libraries that would do a lot of the work - but I don't know about
those. I usually write programs from scratch, and write everything.

Last night, I wrote char *stristr(char *str) because it isn't in the
library - though I'm sure it's somewhere (though I wouldn't know where to
look). I'm rather pleased with it! :-)

Regards,

MikeC

[Ben Bacarisse]

"MikeC" <Mi*******@btco nnect.comwrites :

"August Karlstrom" <fu********@com hem.sewrote in message

<snip>

>How come the functions have different signature and what do you want to
achieve? Please, tell us a bit more about the underlying problem.

<snip>

However, as you ask ...

I haven't finished specifying the program yet - I keep having bigger and
better ideas - but I want to write a text macro engine. It will interpret
commands from a (text) command file, executing them on an input (read only)
file, and producing an output file. The commands will be, for example

copy off // don't copy anythying from the input file to the output file
find_forward "a text string"
move_left 6 // characters
copy on // this causes any character scanned by the cursor to be copied to
the output file
loop 6 // times
{ <more commands>
}
etc....

... you get the idea.
I wanted to run through the command (program) file and compile it into a
forth-like stack (yes, I'm a dinosaur), with each stack element being a
structure, which contains, among other things, a pointer to the function
that will execute the command. The commands do different things, so they
have different signatures, hence my question.

This does not follow automatically from what you have said. I have
done similar things and there is no reason why the functions /need/ to
have different types. One way to look at it is that the functions all
modify the state of a "text copying virtual machine". I.e. each one
takes a pointer to a structure that describes that program's state:
the file positions, variable bindings, stack and so on.

While there is a cost here (all the state get piled into one place)
the payoff is that you don't need a big switch effectively doing
run-time type checking. Remember I said that at the time of the call
the function pointer must be cast to the correct type? You end up
with a messy if-then-else chain (or a switch) resolving the correct
way to call each of the various kinds. It is well worth trying to get
them all to be the same.

--
Ben.

[MikeC]

"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..

"MikeC" <Mi*******@btco nnect.comwrites :

> The commands will be, for example

copy off // don't copy anythying from the input file to the output file
find_forward "a text string"
move_left 6 // characters
copy on // this causes any character scanned by the cursor to be copied
to
the output file
loop 6 // times
{ <more commands>
}
etc....

... you get the idea.
I wanted to run through the command (program) file and compile it into a
forth-like stack, with each stack element being a
structure, which contains, among other things, a pointer to the function
that will execute the command.

This does not follow automatically from what you have said. I have
done similar things and there is no reason why the functions /need/ to
have different types. One way to look at it is that the functions all
modify the state of a "text copying virtual machine". I.e. each one
takes a pointer to a structure that describes that program's state:
the file positions, variable bindings, stack and so on.

While there is a cost here (all the state get piled into one place)
the payoff is that you don't need a big switch effectively doing
run-time type checking. Remember I said that at the time of the call
the function pointer must be cast to the correct type? You end up
with a messy if-then-else chain (or a switch) resolving the correct
way to call each of the various kinds. It is well worth trying to get
them all to be the same.

--
Ben.

Thanks Ben, but I'm not sure I understand what you are thinking about.
The instructions above are a small sub-set of the instructions that will be
available.

find_forward "a text string" takes a string argument.
move_left 6 takes a decimal integer.
add var_2 14 takes a variable and a constant

I will have variables which I can add together, subtract, do simple
arithmetic, etc.

It seems to me all the functions are different. I can't envisage what you
have in mind - but then, you probably have a wealth of experince and
shoulder-rubbing with other programmers. I've been doing it for a long
time, but I have never known anybody else with an interest in it.

I can have a state machine to handle the text, yes, but it will have quite a
lot of buttons to push, and sometimes, two or three buttons in combination
to get it to the next state. Actually, the concept of a state machine had
not occurred to me. Thanks - I'll give that some thought.

What I have in mind would require a degree of pre-compilation, which would
require a switch, but I was planning to use the function pointers to replace
the switch as described in http://www.newty.de/fpt/intro.html. At run-time,
it would use the concepts of the Forth virtual machine, which is a simple,
reverse polish, stack-based machine. Very quick at run time for a
semi-interpreted language.

.... but we're getting quite off-topic. Is there an architecture group that
would be more appropriate?

Thanks,

MikeC

[Ben Bacarisse]

"MikeC" <Mi*******@btco nnect.comwrites :

"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..

>"MikeC" <Mi*******@btco nnect.comwrites :

>> The commands will be, for example

copy off // don't copy anythying from the input file to the output file
find_forwar d "a text string"
move_left 6 // characters
copy on // this causes any character scanned by the cursor to be copied
to
the output file
loop 6 // times
{ <more commands>
}
etc....

... you get the idea.
I wanted to run through the command (program) file and compile it into a
forth-like stack, with each stack element being a
structure, which contains, among other things, a pointer to the function
that will execute the command.

This does not follow automatically from what you have said. I have
done similar things and there is no reason why the functions /need/ to
have different types. One way to look at it is that the functions all
modify the state of a "text copying virtual machine". I.e. each one
takes a pointer to a structure that describes that program's state:
the file positions, variable bindings, stack and so on.

While there is a cost here (all the state get piled into one place)
the payoff is that you don't need a big switch effectively doing
run-time type checking. Remember I said that at the time of the call
the function pointer must be cast to the correct type? You end up
with a messy if-then-else chain (or a switch) resolving the correct
way to call each of the various kinds. It is well worth trying to get
them all to be the same.

--
Ben.

Best not to quote sig blocks.

Thanks Ben, but I'm not sure I understand what you are thinking about.
The instructions above are a small sub-set of the instructions that will be
available.

find_forward "a text string" takes a string argument.
move_left 6 takes a decimal integer.
add var_2 14 takes a variable and a constant

I will have variables which I can add together, subtract, do simple
arithmetic, etc.

It seems to me all the functions are different.

If you start to generalise, I'd bet they merge into a common type.
For example, why have only string literals? If you can:

set myvar next(3)
find_forward myvar

To pick put "abc" and skip to the next "abc". Or

set myvar next(3)
find_forward myvar+myvar

to skip to "abcabc" then suddenly find_forward needs an "expression "
type object just like everything else. And if some operation needs
more than one piece of data, it can be solved by have a way to
represent "tuples" like (42, "a string") as a single value.

Now, you may has a design the does not this generality, so by all
means use separate types, but as you extend the functions of your
program, I bet you will find the types start to come together. This
is a case where generalising early, can help.

I have just finished the message I noted that you are planning on
something like Forth. That makes my plan all the better, but I will
leave this general idea here anyway.

I can't envisage what you
have in mind - but then, you probably have a wealth of experince and
shoulder-rubbing with other programmers. I've been doing it for a long
time, but I have never known anybody else with an interest in it.

That is a shame. It really helps to talk over designs.
comp.programmin g is good place for general discussions.

I can have a state machine to handle the text, yes, but it will have quite a
lot of buttons to push, and sometimes, two or three buttons in combination
to get it to the next state. Actually, the concept of a state machine had
not occurred to me. Thanks - I'll give that some thought.

What I have in mind would require a degree of pre-compilation, which would
require a switch, but I was planning to use the function pointers to replace
the switch as described in http://www.newty.de/fpt/intro.html. At run-time,
it would use the concepts of the Forth virtual machine, which is a simple,
reverse polish, stack-based machine. Very quick at run time for a
semi-interpreted language.

If you are going forth-ish then I think you won't need separate types
at all. All forth opcodes act on "the stack" -- they all have the
same type:

find_forward: pop "thing" from stack, scan for it.
move_left: pop "thing" from stack and treat it as a number f
places to move
add: pop two things. One is treated as a variable name (or
reference) the second is a value.

You will need a way to represent stack values, but all operations just
need the internal scanning state and the stack to do their work.

... but we're getting quite off-topic. Is there an architecture group that
would be more appropriate?

comp.programmin g is the best I can think of.

--
Ben.