🔒 Locked

if-statement oder function-pointer

Started by Mav Mar 10, 2005 at 1:56 PM 4 replies 1.5k views

Original Post

Mar 10, 2005 at 1:56 PM

Hey, I am currently working on an 2d opengl-wrapper and I want to be able to switch between immidiate-mode and a cached mode, by calling a method (eg. CoreObject.SetMode(ogl_immidiate) or something). the drawing functions should stay the same (CoreObject.DrawImage(...);). I could just do a simple if-statement like: CoreObject::DrawImage(..){ if(immidiate_mode) TexMapImmidiate(..); else TexMapCached(..); } or I could have a member-function-pointer to the fundamental drawing-routines and do it like this: CoreObject::DrawImage(..){ (this->*TexMap)(..); } where the pointer either points to TexMapImmidiate() or TexMapCached() and is only change when SetMode is called. This way I wouldn't have to do the if-statement on every call. My question is: is it faster to dereference the member function pointer or to evaluate the if-statement? I know, it makes a *very* marginal difference, but I have to decide this now. Or which of this ways of solving the problem would you consider "cleaner"? thx

ToohrVyk

238

ToohrVyk

Mar 10, 2005 at 2:09 PM

I suggest that you create two implementations of CoreObject: one that implements immediate mode:

ImplementationImmediate::TexMap(..){
/* code of TexMapImmidiate(..) */
}

And another that implements cached mode:

ImplementationCached::TexMap(..){
/* code of TexMapCached(..) */
}

You can then keep such an internal object inside your CoreObject instance, use delete/new to change the implementation smoothly at runtime. You can then use:

CoreObject::DrawImage(..) {
assert( Implementation != 0 );
Implementation->TexMap(..);
}

Every time. This will have the same performance as the two methods you suggested (and unless you intended to hand-optimize your own methods, it will also be faster), but will provide for either a shorter mode change function than the function pointer method or shorter functions than the if-else method.

Fruny

203

Fruny

Mar 10, 2005 at 2:29 PM

Quote:
My question is: is it faster to dereference the member function pointer or to evaluate the if-statement?

Depends on the compiler and its implementation of member function pointers.

Mav

Author

Mav

Mar 10, 2005 at 4:18 PM

thank you for your replies.

Quote:

I suggest that you create two implementations of CoreObject: one that implements immediate mode:

ImplementationImmediate::TexMap(..){
/* code of TexMapImmidiate(..) */
}

And another that implements cached mode:

ImplementationCached::TexMap(..){
/* code of TexMapCached(..) */
}

You can then keep such an internal object inside your CoreObject instance, use delete/new to change the implementation smoothly at runtime. You can then use:

CoreObject::DrawImage(..) {
assert( Implementation != 0 );
Implementation->TexMap(..);
}

Every time. This will have the same performance as the two methods you suggested (and unless you intended to hand-optimize your own methods, it will also be faster), but will provide for either a shorter mode change function than the function pointer method or shorter functions than the if-else method.

wouldn't that mean, that I have to derive ImplementationCached and ImplementationImmediate from an Implementation-base-class supporting the TexMap-method? this would mean, I had to use virtual methods, which may be even slower. And I would still have to dereference the pointer to implemenation.
But I think, I'll just go with the member function pointers. The mode change function only will have to change three pointers and optimizing here will probably not bring any really speed gain.

ToohrVyk

238

ToohrVyk

Mar 11, 2005 at 12:31 PM

Quote:
Original post by Mav
wouldn't that mean, that I have to derive ImplementationCached and ImplementationImmediate from an Implementation-base-class supporting the TexMap-method? this would mean, I had to use virtual methods, which may be even slower.

They will probably be faster. You are using function pointers to emulate what virtual functions do, and since you do not plan to optimize your function pointer code for days to get every nanosecond out of it, the standard, professionally optimized default tried and tested implementation of virtual functions will probably prove faster.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.