#ifdef _DEBUG in main function - c++

Does #ifdef _DEBUG in the main function has any sense if I am working on visual studio 2013 ?
If yes, what it is for ?
int _tmain(int argc, _TCHAR* argv[])
{
#ifdef _DEBUG
//creating some objects, using functions etc;
#endif
}

#ifdef DEBUG or #ifdef _DEBUG are used to handle some code that you use for debugging purposes. If you add #undef _DEBUG or similar to this at the very beginning of your code, the compiler will skip the code contained in #ifdef DEBUG /* bla bla */ #endif.
If you're
//creating some objects, using functions etc;
inside this block and thinking this will work, I assure you, it won't until you include -D_DEBUG in compiler's options during invocation.

for example it can be used to do stuff only in debug compilation ;)
Check your flags specifically to VS, in linux for example, you add NDEBUG to non debug builds.. so check your project properties.. compile command line.. etc..

Related

Is debugging code not going to production in c++? [duplicate]

Does #ifdef _DEBUG in the main function has any sense if I am working on visual studio 2013 ?
If yes, what it is for ?
int _tmain(int argc, _TCHAR* argv[])
{
#ifdef _DEBUG
//creating some objects, using functions etc;
#endif
}
#ifdef DEBUG or #ifdef _DEBUG are used to handle some code that you use for debugging purposes. If you add #undef _DEBUG or similar to this at the very beginning of your code, the compiler will skip the code contained in #ifdef DEBUG /* bla bla */ #endif.
If you're
//creating some objects, using functions etc;
inside this block and thinking this will work, I assure you, it won't until you include -D_DEBUG in compiler's options during invocation.
for example it can be used to do stuff only in debug compilation ;)
Check your flags specifically to VS, in linux for example, you add NDEBUG to non debug builds.. so check your project properties.. compile command line.. etc..

How to view the output of DEBUG conditional statement?

I have written a code with #ifdef DEBUG conditional statement to print cout statement in code blocks. My questions are:
so these conditional Debug will appear only during condition right?
if so how do I view the output in code blocks when I debug the code?
I am not sure about codeblocks but in visual studio you can select if you want to build the debug or release version of the program (or any other version you define). What this effectively does is that it will set the flag DEBUG to true. and you don't need to define a variable manually. In any case you can use your own definition for this.
In the debug version anything inside the #ifdef DEBUG will be also compiled while in the release version these chunks of code will be skipped. To get information from debugging you can define a macro debug print like this.
#define DEBUG_MODE 1 // Or 0 if you dont want to debug
#ifdef DEBUG_MODE
#define Debug( x ) std::cout << x
#else
#define Debug( x )
#endif
and then call your Debug( someVariable ); If you build the debug version you get output in the console otherwise nothing will happen.
As mentioned in other comments/answers you can define a macro such as DEBUG(message) for printing debug messages in debug builds only. However, I suggest you use NDEBUG instead of DEBUG to do so. NDEBUG is a standardized predefined macro that is automatically defined by compiler in release build, if this is your intent. Use it this way :
// #define NDEBUG ==> not needed, this macro will be predefined by compiler in release build
#ifdef NDEBUG // release build
# define DEBUG(msg)
#else // debug build
# define DEBUG(msg) std::cout << msg
#endif
int main(void)
{
DEBUG("this will be printed to console in debug build only\n");
return 0;
}

How to compile so that filenames / line numbers are available for error-reporting tool?

I have a game that is sold on Steam, and as such uses the Steamworks SDK. This has an automatic error-collecting tool as described briefly here.
Every time my game generates an unhandled exception, it is logged on the tool's web site. I've noticed that when the crash occurs on MY development build, the logged crash includes filenames and line numbers. However, when the crash occurs on a user machine, this info is absent.
Is this probably because I have the PDBs on my machine but not the user's machine?
Are there any compilation flags that might bake limited information into the EXE, so that the error reporting tool might be able to grab it?
I realize this is a bit of a longshot question and asked in relation to a specific tool. I asked because I'm hoping there is general knowledge (about compilation flags, etc) which I can apply to my specific situation.
I don't know Steamworks SDK, but will at least try to explain common usage of preprocessor NDEBUG, _DEBUG, __FILE__ and __LINE__ on classic assert.h (taken from Windows SDK / VC include):
#include <crtdefs.h>
#undef assert
#ifdef NDEBUG
#define assert(_Expression) ((void)0)
#else
#ifdef __cplusplus
extern "C" {
#endif
_CRTIMP void __cdecl _wassert(_In_z_ const wchar_t * _Message, _In_z_ const wchar_t *_File, _In_ unsigned _Line);
#ifdef __cplusplus
}
#endif
#define assert(_Expression) (void)( (!!(_Expression)) || (_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
#endif /* NDEBUG */
Release Build usually disables asserts by defining NDEBUG while Debug Build usually leave NDEBUG undefined (to enable asserts) and include _DEBUG for additional checks (while Work Build may have both undefined). Look at the definition of assert:
#define assert(_Expression) (void)( (!!(_Expression)) \
|| (_wassert(_CRT_WIDE(#_Expression), \
_CRT_WIDE(__FILE__), __LINE__), 0) )
If everything else fails (defining/undefining NDEBUG / _DEBUG) you can use __FILE__ and __LINE__ yourself - to include that in whatever message string you are passing to the engine (or to those exceptions you may throw).
I'm going to presume you export code in Release Mode in Visual Studio, as opposed to Debug.
Visual Studio removes (by optimizing) some debugging elements, such as Memory Logging (_CrtDumpMemoryLeaks), but I am not an expert in what it does and doesn't remove. I would start with the link below, which covers debugging in release mode.
http://msdn.microsoft.com/en-us/library/fsk896zz.aspx

#ifdef _DEBUG release mode in vs 2008

There are some part of my project which don't function in release mode. I can check it by using printf and it doesn't print anything. I'll show you in this following code:
void SNKsomething::vGetState()
{
#ifdef SNK_STH
for(int i = 0; i < 2; i++)
{
printf("sth\n');
}
Additionally, SNK_STH is defined in files Globals.h as following
#ifdef _DEBUG // in Project properties
#define SNK_STH
#else
// .....
So, I don't see sth which I print it in release mode. I want to know that I have to do something about _DEBUG in project properties of VS-2008. don't I?
_DEBUG is a preprocessor macro. If you right click on properties and go to c/c++, preprocessor is one of the options.
Preprocessor definitions are different for release and debug. If you add SNK_STH to the release preprocessor macros you will see your printf.
If you want to see the code in both debug and release, consider pulling it out of the ifdef.
I've had problems with the _DEBUG Macro, what I found very usefull is the
IsDebuggerPresent function
which returns a boolean:
If the current process is running in the context of a debugger, the return value is nonzero.
If the current process is not running in the context of a debugger, the return value is zero.

Compiling with Ogre + MFC in _DEBUG mode

There is a problem compiling Ogre with MFC in debug mode, you get an error because of the MFC macro:
#ifdef _DEBUG
#define new DEBUG_NEW
Which basically clobbers Ogre's debug new -
#define OGRE_NEW new (__FILE__, __LINE__, __FUNCTION__)
I'm trying to get MFC+Ogre to run merrily together in DEBUG mode, and I got it to compile with:
#ifdef _DEBUG
#undef new
#endif
Ogre::Root * root = OGRE_NEW Ogre::Root( pluginsFile, "ogre.cfg", "Ogre.log" );
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
But now, I get a runtime error: Ogre::InternalErrorException
Anybody else face/solve this problem?
You may need to remove the MFC debug macro rather than the Ogre one. Check this article on the Ogre Wiki here titled Common Mistakes Ogre Wiki
I think this might be a problem in the specific machine I was using. I tried this out on another machine, and it seemed to work in debug mode with the #ifdefs #undefs as shown above.