#### Archived

This topic is now archived and is closed to further replies.

# C++ pointers to functions - A clean solution!

This topic is 5674 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

After much searching on the web I found the following clean solution to using function pointers without all that ugly messing with static (wrapper) function or templates....

class cFOOBAR
{
public:
bool (cFOOBAR::*mpRender)(int AnyArg);

bool RenderThis (int Arg);
bool RenderThat (int Arg);

inline bool Render (int Arg)
{
return ((this->*mpRender) (Arg));
}
};

bool cFOOBAR::RenderThis (int Arg)
{
printf ("RenderThis(%d) called\n", Arg);
return (true);
}

bool cFOOBAR::RenderThat (int Arg)
{
printf ("RenderThat(%d) called\n", Arg);
return (true);
}

void main (void)
{
cFOOBAR		foobar;

foobar.mpRender = foobar.RenderThis;
foobar.Render (42);

foobar.mpRender = foobar.RenderThat;
foobar.Render (123);
}

The trick is in the brackets around mpRender in the Render() function, and also giving the function pointer an object for context - the explicit "this->" is required. Some of you will probably have already known this, but for the rest of us who have struggled with the crap way c++ previously seemed to have no way of cleanly doing something which c handles so easily - I hope this helps.

##### Share on other sites
quote:
Original post by Beelzebub
The trick is in the brackets around mpRender in the Render() function

Right, but why are you adding extra brackets on return statements? You do realise that return is not a function, and the brackets are superfluous, right?
quote:

Some of you will probably have already known this, but for the rest of us who have struggled with the crap way c++ previously seemed to have no way of cleanly doing something which c handles so easily - I hope this helps.

How can you claim C handles member function pointers cleanly, when it doesn''t even have member functions?

##### Share on other sites
I don''t understand what problem is being cleanly solved here. Can you give examples of ''that ugly messing with static (wrapper) function or templates.''

##### Share on other sites
quote:
Right, but why are you adding extra brackets on return statements? ... and the brackets are superfluous, right?

Yes the outer set of brackets is superfluous, it''s just the way I format my code.

quote:
You do realise that return is not a function,

What the fuck are you on??? Ofcouse return is not function! Having brackets is allowable under ansi-c so I use them. I also put brackets around sizeof(int) and use them in expressions (such as x=(5*8)+2), too me it''s easiler to read and does not require knowledge of the opperator presicence table - which differs on some of the non-ansi C compilers I have used.

##### Share on other sites
quote:

Can you give examples of 'that ugly messing with static (wrapper) function or templates.'

See section 3.5 of "http://www.function-pointer.org/CCPP/callback/callback.html#chapter3"

[edited by - Beelzebub on February 2, 2003 11:59:07 AM]

##### Share on other sites
They're not the same thing.

The linked examples are so that you can just call the static function, passing the object to the function, which then does what you do by calling the function on the object. Your code needs the object. They're not the same thing.

[edited by - petewood on February 2, 2003 12:40:18 PM]

##### Share on other sites
My point is that until I found out what I did, the only way I had previously been able to implement pointers to member-functions, was using static functions (as in the link).

In C the following works fine

void (*pfunc)(void);
pfunc = somefunc;
pfunc ();

But I could never get the c++ version to compile, errors like "term does not evaluate to a function" would occur on line doing the calling...

void (cCLASS::*pfunc)(void);
pfunc = some_class_func;
pfunc (); <- compile error

C++ seems to have some ''difficulty'' doing the implicate de-referencing of the pointer which C does automatically.
Then having to add the brackets around the de-reference, then having to explicitly give it an object to work on, it all seems like a black-art.

[rant]
The "How to I use pointers to functions in C++" is a thread that reoccurs about once a month on here, so I thought I''d do fellow programmers a favor and post a solution which didn''t involve all that tedious mucking around in static functions.

If you''re saying I shouldn''t share such information with wider development community, I''ll clear off and leave you to yourselves.
[/rant]

##### Share on other sites
I don''t really get this thread. You are saying that you have discovered that C++ supports pointers to member functions(which half the population around here already knew)? Or is there something else going on here thats beyond me?

Have you tried passing one of your newly discovered pointers to an API that expects a standard C-style function pointer? No? That is why people are "messing with static functions".

"I know very well who Satan is: He is freedom. He is the uncontrolled, the incalculable, the antithesis of order and discipline, the antithesis of the legalism of outer space.... We know where a planet will be in twelve years, four months and nine days. But we don''t know where a butterfly will have flown one minute hence. Therefore the butterfly is of Satan."
-- Jens Bjørneboe

##### Share on other sites
You can''t pass a pointer to bool cFOOBAR::Render(int Arg) to a C API (like windows or opengl). It needs to be static. You haven''t solved the problem that static functions solve. You''ve shown how to store a pointer to a member function and call it. That''s all.

##### Share on other sites
quote:
Original post by Beelzebub
What the fuck are you on??? Ofcouse return is not function!

Keep your hair on. There are plenty of people who follow this weird idea of putting brackets around the argument to return.
quote:

Having brackets is allowable under ansi-c so I use them. I also put brackets around sizeof(int) and use them in expressions (such as x=(5*8)+2), too me it''s easiler to read and does not require knowledge of the opperator presicence table - which differs on some of the non-ansi C compilers I have used.

Oh, so you employ superstitious practices rather than being clear on what the rules are.

1. 1
2. 2
3. 3
4. 4
frob
15
5. 5

• 20
• 12
• 13
• 14
• 84
• ### Forum Statistics

• Total Topics
632144
• Total Posts
3004419

×