S
S?ren Gammelmark
Hi
I have been searching the web and comp.lang.c of a method of using
variable-argument function pointers and the like. And some of the
questions arising in this post are answered partly in these posts, but
I ask mainly for a way to found a way to solve this problem. I'm a
hobbyist so there might be an alltogether better solution to the
problem, so please come with any solution you might think of. I'm open
to ideas. --- And i'm not bound by C. Suggestions from C++ are
welcome.
I need an extensible multithreaded application (i'm thinking windows
here since I have no experience on other systems, but I think the
problem is quite similar on other os). I would like to make the
extensibility as natural for the user-programmer as possible without
that programmer needing to think (very much) about multithreading. For
this reason I would like the user-programmer to be able to define a
function like this:
int Filter1(DataSegment segment, float a, float b, int value);
int Filter2(DataSegment segment, float start, float end);
then in the program itself, it should be possible to make a call
something like this
InvokeFilter(&Filter1, 0.5f, 43.0f, 120);
or
InvokeFilter(&Filter2, 0.2f, 1.2f);
InvokeFilter should then be able to spawn the necessary threads and
call Filter1 with the arguments 0.5f, 43.0f, 120 (and an appropriate
DataSegment, which tells the filter where to operate). My first
thought of solving this problem was to define a function-pointer of
the form
typedef int (*PROC_MULTITHREAD)(DataSegment segment, ...);
and then define InvokeFilter as
int InvokeFilter(PROC_MULTITHREAD filter, ...)
where InvokeFilter will call the function pointed to by filter, and
pass the extra (...) arguments. But as I have read around the net,
this is not supported by C (which I find a bit odd, since I can't see
the essential difference.). It is not possible for me to define som
general model which all filter-functions will conform to. The obvious
solution is ofcourse to implement a list containing the arguments, but
I think it would be somewhat annoying for the programmer of the
filter-functions to use some object for retrieving arguments.
Comments? Suggestions?
Søren Gammelmark
I have been searching the web and comp.lang.c of a method of using
variable-argument function pointers and the like. And some of the
questions arising in this post are answered partly in these posts, but
I ask mainly for a way to found a way to solve this problem. I'm a
hobbyist so there might be an alltogether better solution to the
problem, so please come with any solution you might think of. I'm open
to ideas. --- And i'm not bound by C. Suggestions from C++ are
welcome.
I need an extensible multithreaded application (i'm thinking windows
here since I have no experience on other systems, but I think the
problem is quite similar on other os). I would like to make the
extensibility as natural for the user-programmer as possible without
that programmer needing to think (very much) about multithreading. For
this reason I would like the user-programmer to be able to define a
function like this:
int Filter1(DataSegment segment, float a, float b, int value);
int Filter2(DataSegment segment, float start, float end);
then in the program itself, it should be possible to make a call
something like this
InvokeFilter(&Filter1, 0.5f, 43.0f, 120);
or
InvokeFilter(&Filter2, 0.2f, 1.2f);
InvokeFilter should then be able to spawn the necessary threads and
call Filter1 with the arguments 0.5f, 43.0f, 120 (and an appropriate
DataSegment, which tells the filter where to operate). My first
thought of solving this problem was to define a function-pointer of
the form
typedef int (*PROC_MULTITHREAD)(DataSegment segment, ...);
and then define InvokeFilter as
int InvokeFilter(PROC_MULTITHREAD filter, ...)
where InvokeFilter will call the function pointed to by filter, and
pass the extra (...) arguments. But as I have read around the net,
this is not supported by C (which I find a bit odd, since I can't see
the essential difference.). It is not possible for me to define som
general model which all filter-functions will conform to. The obvious
solution is ofcourse to implement a list containing the arguments, but
I think it would be somewhat annoying for the programmer of the
filter-functions to use some object for retrieving arguments.
Comments? Suggestions?
Søren Gammelmark