Cost of Function Pointers (using them)?

Started by
25 comments, last by crakinshot 20 years, 5 months ago
Does anyone know the cost in terms of ticks for using function pointers? I need to use the notion of virtual functions without actually using them (costs to much)... Base-Time template diriving - (as described in: http://www.gamedev.net/reference/programming/features/impperfcpp/) - cant be used because I still need the run-time side; so I was thinking about using function pointers and derived classes that would register their version and save it within a function pointer of the base class. logically it should work... but I'm just wondering what the cost would be to call a function pointer (with operands)... Thanks David [edited by - crakinshot on November 8, 2003 8:06:39 AM]
-=CrAKiN:ShOt=-I could put something witty here but I'm not that stupid...
Advertisement
You "know" that virtual functions "cost too much", but don''t "know" what function pointers "cost"?

No offense, but, ... nevermind. I''ll bite my tongue for you.
If you''re all that desperate for speed you could look up static polymorphism using templates, with policies and that stuff. But, I can almost guarantee that you''re not gonna notice the overhead of virtual function calls. Good luck!
well I "know" that virtually (run-time look up) called functions cost 24 ticks without additional variables... what I "don''t know" is how many ticks a function pointer (direct) costs...

is it slower? faster?

I dont know why you have to bite your tongue.... please if I''ve got something wrong, please dont bite your tongue and and tell me so that I dont make the same mistake again... I dont pretend to know everything...
-=CrAKiN:ShOt=-I could put something witty here but I'm not that stupid...
void foo() { }void (*foo_ptr)() = foo; 


this doesn''t cost anything ( calling foo_ptr() is same fast as calling foo() directly ).

for accessing member functions i''ve been using boost::function, and there is nearly no expense in it.

how exactly do you want to store a classes version in a function pointer?

our new version has many new and good features. sadly, the good ones are not new and the new ones are not good
quote:Original post by Anonymous Poster
If you''re all that desperate for speed you could look up static polymorphism using templates, with policies and that stuff. But, I can almost guarantee that you''re not gonna notice the overhead of virtual function calls. Good luck!


hehe... its annyoning... everyone saying classes and their abilitys are evil and slow... (then they use their optimal code with template strings instead of unsigned char*... Heheh...
-=CrAKiN:ShOt=-I could put something witty here but I'm not that stupid...
quote:Original post by 666_1337
how exactly do you want to store a classes version in a function pointer?


something like (probably wrong code - but general idea):

class A{public:    void (*foo_prt)(int a, int b); //pointerprotected:    void register_foo((*foo)){foo_prt=foo;}};class B : public A{public:   void foo_B(int a, int b);   B() {register_foo(foo_B);}};


so now if at run time I called foo() on a list of A items each would call their dirived versions directly.

I've only been looking at this stuff for an a few hours so I dont know the exact code but its the general idea...


[edited by - crakinshot on November 8, 2003 8:55:39 AM]
-=CrAKiN:ShOt=-I could put something witty here but I'm not that stupid...
how do you think a virtual function call is made?
thru a function pointer!
I have to agree with emilk really... a virtual function works through the rtti mechanism, and looks up the function pointer through the vtable. You can only speed this up using the templating mechanism described admirably in todays featured articles.
yes but it is having to look up the vtable every time you call the base function.... you define the function to call within a member function then it will directly invoke that function instead of having to look up dymanically. i.e. your derived classes set the base function pointer and then all calls to it call that which is set.

I dont know... it seems a logical approch if you dont want the virtual lookup each time without using compile-time deriving (templates).
-=CrAKiN:ShOt=-I could put something witty here but I'm not that stupid...

This topic is closed to new replies.

Advertisement