Sign in to follow this  
Lucas W

#ifdef or if? [solved]

Recommended Posts

Hi all. In my engine, I would like to check to see if the programmer wants to use shaders. So I wrote some shader-management code but Im unsure about which method would be the best to use to check if the shaders are enabled in my render-loop. Should I use #ifdef or just a simple 'if' statement? Which is the least expensive to use and which should I use? It would be nice if someone could explain the difference between those two aswell :) This is an example of what I mean:

Should I use this:

Engine::Render()
{
    ...

    #ifdef (USE_SHADER)
    {
    shader->enable(...);
    ...
    }

    Render();
}

Or Should I use this:

Engine::Render()
{
    ...
    
    if(mShadersEnabled)
    {
    shader->enable();
    ...
    }

    Render();
}




Can someone please enlighten me? [Edited by - Lucas W on July 3, 2008 2:32:52 PM]

Share this post


Link to post
Share on other sites
Defiantly use a regular old if(bool).

#ifdef is a preprocessor message to the compiler, it is not meant to be used for regular program control the way you want to use it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lucas W
It would be nice if someone could explain the difference between those two aswell


#ifdef is a pre-processor command. When you do:
#ifdef SOMETHING
...
#endif

The pre-processor will strip out the code between the #ifdef and the #endif when SOMETHING is not defined. So, code in #ifdef statements will conditionally not get compiled. This is useful when, for example, you want to write platform-specific code in a project targeting multiple platforms:
#ifdef SOME_PLATFORM
//code specific to SOME_PLATFORM
#endif

if statements check a boolean value at run-time and takes the code path within the if {...} when that value is true.

Share this post


Link to post
Share on other sites
You must make the decision whether you want to control the property USE_SHADER at compile- or at runtime!

Generally speaking, preprocessor definitions can be quite useful to write portable code or to add special debug or profiling code in some builds. When you build the final release of your application you can simply remove the preprocessor #define and no debug code ships to the end-user's PC.

In your case I thing it could be quite useful to be able to control the property at runtime so if() is propably the better choice.

Best regards,
Alexander

Share this post


Link to post
Share on other sites
Thanks for all the great answers.

Now, I don'r realy know if I would like to check the statement at compile time or runtime. Because if the game doesnt use shaders att all - checking if the user wants to use shaders will decrease the fps, right?

But is a if() every frame realy that bad? Or how should I solve this?

Share this post


Link to post
Share on other sites
Quote:
Original post by Lucas W
But is a if() every frame realy that bad? Or how should I solve this?


Probably not. Try it, profile your code, and if it's a bottleneck, optimize it.

Share this post


Link to post
Share on other sites
If an 'if' statement is killing your frame rate, you probably have bigger things to worry about...

Anyway, profiling is the act of utilizing a tool to identify where you program is spending the majority of its time when it is running. It allows you to focus on optimizing the areas of your program that are running the most, instead of writing micro-optimizations in spots that may only end up running 1% of the time...

Share this post


Link to post
Share on other sites
You could go with the "try it and see" approach.

As a beginner C or C++ programmer, it's probably not going to be the thing you'll do that slows down the program the most.

Share this post


Link to post
Share on other sites
Quote:
Original post by Lucas W
How could I optimize an if()?


Optimize the higher level logic around the if.

Quote:

Btw, what is profiling?


Performance analysis. Don't guess at what parts of your code may be slow, because you'll guess wrong. Use tools to tell you where your biggest slow downs are, so you know where to focus your optimizations.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this