On Thu, 2010-11-04, Alessandro Basili wrote:
> On 11/3/2010 10:58 PM, Jorgen Grahn wrote:
....
>> What are you trying to accomplish? Perhaps there is a solution to
>> your problem which doesn't involve knowing the names of your
>> functions.
>>
>
> I have implemented a state machine, using pointers to function for
> states. The dispatcher provides events to the states and a change in the
> state is simply accomplished changing the "state" pointer to yet another
> function (the layout of the program can be found here:
> http://www.netrino.com/Embedded-Syst...Driven-Systems,
> in listing 1,2 and 3).
>
> I found the approach quite nice and easily scalable to more complex
> problems, without having the need to maintain any table (events, states)
> or the burden of so many switch/case scattered around.
>
> My problem though is that in this approach is not quite easy to print in
> which state I am, since the state is represented only by the function
> pointer. That is why I thought that having the possibility to get the
> name of the function from its pointer would have helped me out.
Ah, good. Now I see what you want and why.
I guess I'd go: "Damn, it's hard to print what state I'm in. Oh well
-- maybe I don't really need to print that after all." And then I'd
wait until I had an urgent need to print that info.
If it's just for debugging (which IMHO it should be) I'd probably be
satisfied with seeing the function pointers in hex, knowing I can
translate them to names if I want to (using nm(1) on Unix).
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .