Function Pointers within Classes
Hi, I am trying to make function pointers operate within classes.
eg, have a function pointer as a member variable which points to the particular function required to render that class instance graphics to the screen.
So far I have found that the only way I could get function pointers to work inside a class, was to make the functions which will be pointed to as ''static''. Now by doing this, those static functions are essentially not related to a class instances data at all, and I have to pass an instance pointer to the function in order to use its variables eg
someClass someClass1 = new someClass();
someClass1->functionpointerRender(someClass1);
This seems a bit counter productive to me.
Is there any way to use function pointers within classes???
Thnx
Cel
Cel aka Razehttp://chopper2k.qgl.org
Ok, two ways out:
The ''class'' way -
[source]
class Renderer {
...
virtual void RenderPolys(Poly* ThePolys) = 0;
};
// Classic Polymorphism
class DirectXRenderer {
...
//implements RenderPolys()
};
class OpenGLRenderer {
...
//implements RenderPolys()
};
class World {
private:
Renderer* TheRenderer;
...
public:
void Render();
};
void World::Render() {
TheRenderer->RenderPolys(Self);
TheRenderer->RenderPolys(World);
//etc.
}
//Remember to assign a instance of Renderer to the World''s TheRenderer:
Renderer* MainRenderer = new OpenGLRenderer;
World->AssignRenderer(MainRenderer);
//Don''t forget to delete the renderer at the end of the prog:
delete MainRenderer;
[\source]
If you have BCB, you can simply use closures:
[source]
typedef void (__closure)(*RenderPoly)(Polys* ThePolys);
class World {
private:
RenderPoly* RenderPolyFunc;
//rest same as above
};
void World::Render() {
RenderPoly(Self);
RenderPoly(TheWorld);
}
[\source]
If you don''t, you can emulate closures. I have no time to show you how (got to go soon). But, a closure is simply a pointer with two pointers inside of it: a class (object) pointer, and a function pointer. Also, I think the STL has something that emulates it (something like mem_fun?).
Anyways, got to go,
------------------------------
What should I put here? You tell me.
The ''class'' way -
[source]
class Renderer {
...
virtual void RenderPolys(Poly* ThePolys) = 0;
};
// Classic Polymorphism
class DirectXRenderer {
...
//implements RenderPolys()
};
class OpenGLRenderer {
...
//implements RenderPolys()
};
class World {
private:
Renderer* TheRenderer;
...
public:
void Render();
};
void World::Render() {
TheRenderer->RenderPolys(Self);
TheRenderer->RenderPolys(World);
//etc.
}
//Remember to assign a instance of Renderer to the World''s TheRenderer:
Renderer* MainRenderer = new OpenGLRenderer;
World->AssignRenderer(MainRenderer);
//Don''t forget to delete the renderer at the end of the prog:
delete MainRenderer;
[\source]
If you have BCB, you can simply use closures:
[source]
typedef void (__closure)(*RenderPoly)(Polys* ThePolys);
class World {
private:
RenderPoly* RenderPolyFunc;
//rest same as above
};
void World::Render() {
RenderPoly(Self);
RenderPoly(TheWorld);
}
[\source]
If you don''t, you can emulate closures. I have no time to show you how (got to go soon). But, a closure is simply a pointer with two pointers inside of it: a class (object) pointer, and a function pointer. Also, I think the STL has something that emulates it (something like mem_fun?).
Anyways, got to go,
------------------------------
What should I put here? You tell me.
Hey!
The [source] tags didn''t work!
*petulantly* not fair!
Never mind...
The [source] tags didn''t work!
*petulantly* not fair!
Never mind...
Hey!
The [source] tags didn''t work!
*petulantly* not fair!
Never mind...
------------------------------
What should I put here? You tell me.
The [source] tags didn''t work!
*petulantly* not fair!
Never mind...
------------------------------
What should I put here? You tell me.
Hi, thanks for responding.
Um looking through your code, I cant help but feel that it basically comes to the same conclusion.
You still have a call to the function pointer, and have to pass it the object that is calling it.
ie. TheRenderer->RenderPolys(Self);
I realise this is because the function pointer is in fact pointing to an instance of a separate class, but I need to change functions rapidly at arbitrary times.
Essentially I will be using function pointers to render, for example particles in a particle system with each particle having its own state and therefore one of a range of different rendering functions.
I initially had a Render() function which compared a state variable and THEN launched the appropriate sub render function, but this means that a conditional loop has to be calculated EVERY time I go to render a particle. I changed it to use function pointers instead, so when a state change occurs, the render function pointer simply is pointed to a new render function. This works ok except for the fact that I still have to pass the function a reference to the calling object instance. Using separate classes to define rendering functions is a good idea like you have done, but still requires the caller to pass itself on.... :[
Still thats gotta be faster than doing a conditional loop for every call to render a particle.....
Thanks anywayz, Cel
Um looking through your code, I cant help but feel that it basically comes to the same conclusion.
You still have a call to the function pointer, and have to pass it the object that is calling it.
ie. TheRenderer->RenderPolys(Self);
I realise this is because the function pointer is in fact pointing to an instance of a separate class, but I need to change functions rapidly at arbitrary times.
Essentially I will be using function pointers to render, for example particles in a particle system with each particle having its own state and therefore one of a range of different rendering functions.
I initially had a Render() function which compared a state variable and THEN launched the appropriate sub render function, but this means that a conditional loop has to be calculated EVERY time I go to render a particle. I changed it to use function pointers instead, so when a state change occurs, the render function pointer simply is pointed to a new render function. This works ok except for the fact that I still have to pass the function a reference to the calling object instance. Using separate classes to define rendering functions is a good idea like you have done, but still requires the caller to pass itself on.... :[
Still thats gotta be faster than doing a conditional loop for every call to render a particle.....
Thanks anywayz, Cel
Cel aka Razehttp://chopper2k.qgl.org
I was reading over particle engine code yesterday, and well, here''s my advice
A particle should have a bunch of trajectory variables, 16 or so;
a position, velocity, acceleration, & jerk for the x,y,z axi.
You could probably drop jerk if they aren''t moving very far.
And a some color varibles, starting, ending, burst, diffuses, or whatever you need for it, and maybe a few more to control flicker or fading.
If you want to be object orientented, then you make a container class for each type of particle you want. If you want particle to change from one type to another, you destroy it in the one container and make a new one in the other. There should only be one render function for all the particles of a given type, and it only needs to be called once per frame. Use an array to keep track of the particle data, and rip through it on render; update the position, change the color, set the alpha, next particle. If the array is empty, just bail out of the render function.
Then you don''t need any function pointers (or, gag, virtuals), just two or three different types of particle renders. Spark, cloud, and bolt?
P.S. It is possible to have method pointers, someone on the board here helped me with them, but I abanded the idea becuase it doesn''t really gain you anything. You /must/ pass it ''this'' one way or another, and calling a seperate render function for each object in the game is not a good idea. Calling a render function for each type of object is a more efficient method.
$0.02
A particle should have a bunch of trajectory variables, 16 or so;
a position, velocity, acceleration, & jerk for the x,y,z axi.
You could probably drop jerk if they aren''t moving very far.
And a some color varibles, starting, ending, burst, diffuses, or whatever you need for it, and maybe a few more to control flicker or fading.
If you want to be object orientented, then you make a container class for each type of particle you want. If you want particle to change from one type to another, you destroy it in the one container and make a new one in the other. There should only be one render function for all the particles of a given type, and it only needs to be called once per frame. Use an array to keep track of the particle data, and rip through it on render; update the position, change the color, set the alpha, next particle. If the array is empty, just bail out of the render function.
Then you don''t need any function pointers (or, gag, virtuals), just two or three different types of particle renders. Spark, cloud, and bolt?
P.S. It is possible to have method pointers, someone on the board here helped me with them, but I abanded the idea becuase it doesn''t really gain you anything. You /must/ pass it ''this'' one way or another, and calling a seperate render function for each object in the game is not a good idea. Calling a render function for each type of object is a more efficient method.
$0.02
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
September 24, 2000 12:33 AM
What you guys are looking for are pointers to member functions. Check your C++ reference.
I''ve probably got the exact syntax wrong, but it goes something like:
-Mike
I''ve probably got the exact syntax wrong, but it goes something like:
class Foo{public: typedef void (Foo::*RenderFunc)(); RenderFunc Render; // the pointer void RenderFunc1(); void RenderFunc2(); Foo() {Render = RenderFunc1;}};void main(){ Foo *renderer = new Foo; renderer->*Render(); // Note the ->*}
-Mike
Heya, I cant divide each object into its own class exactly because over an objects lifetime, its state might change to *require* a different rendering method, using the same data it already holds. Creating a new object, copying all the values across and then rendering from that object is a bit of a waste.
Um Mike, I did play around with that sort of structure but I had no luck :[
just tried with your code and it doesn''t compile either :/
In order to assign a function pointer within a class, the function''s address must be given eg
functionPointer = &(Foo::renderer1);
otherwise it doesnt like it.
However even after this, the ->* method doesnt work, but if its called simply with -> it *appears* to work (compiles/runs), but in fact doesnt execute the contents of the function being pointed to.
I have my particle system running at the moment with static rendering functions so I can use function pointers, but I still have to pass it the calling object.
No big deal I spose, but I just thought there would be some way to do it without passing the object that is calling it.
In any case, how it is now is not ideal, but its still faster than going through a conditional loop, or spawning a different type of object and copying the data over.... :/
Thanks guys, Cel
Um Mike, I did play around with that sort of structure but I had no luck :[
just tried with your code and it doesn''t compile either :/
In order to assign a function pointer within a class, the function''s address must be given eg
functionPointer = &(Foo::renderer1);
otherwise it doesnt like it.
However even after this, the ->* method doesnt work, but if its called simply with -> it *appears* to work (compiles/runs), but in fact doesnt execute the contents of the function being pointed to.
I have my particle system running at the moment with static rendering functions so I can use function pointers, but I still have to pass it the calling object.
No big deal I spose, but I just thought there would be some way to do it without passing the object that is calling it.
In any case, how it is now is not ideal, but its still faster than going through a conditional loop, or spawning a different type of object and copying the data over.... :/
Thanks guys, Cel
Cel aka Razehttp://chopper2k.qgl.org
September 25, 2000 02:21 PM
I did say that the syntax might be a bit off. And not needing a "&" is a VCism I guess, it takes it fine.
Here''s a tested version, works in VC on NT and g++ on SunOS:
-Mike
Here''s a tested version, works in VC on NT and g++ on SunOS:
#include class Foo{public: typedef void (Foo::*RenderFunc)(); RenderFunc pRender; // the pointer void RenderFunc1() {printf("RenderFunc1\n");} void RenderFunc2() {printf("RenderFunc2\n");} void Render() {(this->*pRender)();} // Note the ->* Foo() {pRender = &RenderFunc1}};void main(){ Foo *renderer = new Foo; renderer->Render(); renderer->pRender = &Foo::RenderFunc2; renderer->Render();}
-Mike
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement