Hello guys could anyone explain what is the point in: #define DEBUG and #define NDEBUG?
when should we use them and how?? I'd like to see some examples
any help is highly appreciated

depends on the compiler. Generally, DEBUG is defined when you want to compile the program for debugging -- the compiler adds a great deal of symbol information and data so that you can use a debugger to single-step through the program and view the value of variables at any given time. All that is compiler dependent. With Microsoft Visual Studio you don't have to explicitly define DEBUG because the MS compiler with do that for you when you select Debug build (instead of Release build). DEBUG affects the entire program instead of just certain parts.

ok. but what about RELEASE mode??? why I used to see people defining DEBUG?? eg: #define DEBUG, #define NDEBUG, #define _DEBUG
could you provide some examples showing the point in using that?
Thank you too much in advance

When you define DEBUG you can adjust what your code does based on this definition.

So you could do;

#define _DEBUG
#include <iostream>

int main(int argc, char** argv)
{
#ifdef _DEBUG
    std::cout << "DEBUG MODE ON" << std::endl;
#else
    std::cout << "DEBUG MODE OFF" << std::endl;
#endif

    return 0;
}

In this case, when you compile, only the line of code that says "DEBUG MODE ON" is compiled into the application, the other condition is completely skipped and not part of the binary.

Many people do this when developing for cross-compatibility. Such as #ifdef _WIN32 so you can switch between code that will only work on a particular system.

ok got it thnak you too much. at last would you explain a bit Release mode?

Well, release mode is where you put in all your optimisations. The idea is that in release mode you want your application to un as efficiently as possible. Also, any test data or settings you might've set need to be removed. By going into "Release" mode, you have the option to turn these off without altering the code of your application. Strictly speaking, "Release" mode is just a configuration, you could have "Release_64" for 64bit releases or "Release_OGL_FPS" which is release mode with opengl and an fps counter...

What you do in release mode is pretty much up to you as the developer.

As Ketsuekiame says, be aware that there is no strict definition of "Debug mode" and "release mode". If your IDE provides these two modes, all it does it turn on or off a number of compiler options depending on which mode you pick; options chosen by someone else with the intention of being mostly useful to most people.

In debug mode, they probably select for you a number of options that make the code easier to debug; includes debugging symbols, turn off optimisations, give variables special values, and so on. In release mode, they probably select for you a number of options that make the code run faster, or reduce the size of the output file, or some other such choice.

They're no more than pre-selected options, and there's nothing stopping you getting into it and picking them for your own exact needs.

ok that's genius. thank you

Now what I get from the above example you gave me is: defining DEBUG will nake the compiler compiles some block and skip other eg:

#define DEBUG
#include <iostream>
using namespace std;

int main(int argc, char *argv[])
{                                          
#ifdef DEBUG
    {
    cout<<"DEBUG defined!\n";
    }
#else
    {
    x,*
    fsdfsd
    465
    }
#endif
}

this program as I understood from what you explained will compile correctly and never comlains of what wrote in the #else block because it is skipped by the compiler.
if we undefine DEBUG then the compiler will compile the else block and as expected will catch the compile-time error.
Is this a good understanding????
*** I know now that if we used if/else not #if/#else the compiler will catch the errors even the condition succeds or fail?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.