7 Aug
2011
7 Aug
'11
12:10 a.m.
On 08/07/2011 12:06 AM, Florian Paul Schmidt wrote:
On 08/07/2011 12:03 AM, Florian Paul Schmidt wrote:
OMG, could this be the one single place where polish notation would have
a place? To clarify: Encode the signature of functions in the name of
the function and restrict yourself to several function signatures that
cover the kind of functions you want to expose. Then you could cast into
the appropriate type and again use boost::bind..
Ugly, am I on crack? Who knows? Going to party now. Laters,
Flo
I guess though, that one could try a little dirty
hack parsing the
symbol table of the target process to simplify lookup of functions to
call. Assume you want to be able to just send the rendering process a
command via the network, like
["/filter_set_frequency", 1, 0.2]
(assuming OSC style commands)
meaning: call the function filter_set_frequency with the arguments 1
and 0.2. where 1 is the number of the filter and 0.2 the frequency..
The rendering process would have a non-RT thread in which it receives
network commands. The receiver process could parse the output of a
dlsym function call on itself to get a function pointer to the
function filter_set_frequency. Then it would use a boost::bind object
to bind the arguments to it and pass this functor as command to the
RT thread of the rendering process. No explicit hacking of command
tables or what not, would be needed.. Member function handling would
be a bit more difficult. I have to think about this a bit..
Actually, type safety would go out of the window, as the signature of
a function is not really apparent from the symbol table. So some
caution would have to be used when sending commands, making sure that
the types of arguments are right. Before creating the boost::bind
functor the raw function pointer from dlsym would have to be cast to
the right type.. Maybe boost::bind would be the wrong approach here
alltogether.. Will need to think about it a bit more..