_DEBUG symbol preprocessor - significance

[ranga.narasimhan]

Hi,

Can someone explain what exactly this paragraph means or what the significance is? Although I have done few ARX code before, I always had problems when I add / remove headers even a little bit away from the standard.

-Ranga

[daniel_cadext]

 DEBUG links with other libraries built in DEBUG mode and may use the DEBUG C run-time library.

"Some C run-time functions and C++ operators behave differently when called from a debug build of an application."

https://learn.microsoft.com/en-us/cpp/c-runtime-library/debug-routines?view=msvc-170

AutoCAD and the Object ARX libraries are built in release mode, linked with the Release CRT, so you should not mix the two.

I haven't used it myself, but I believe it adds a wrapper, where DEBUG can be defined within a limited scope and will also trigger a compiler warning.

Typically, I add my own preprocessor definition to the Debug configuration, e.g., PYRXDEBUG=1. This allows you to create custom assert and logging macros.

[ranga.narasimhan]

Thanks @daniel_cadext for the detailed response. That kinda explain things. But my question's intent was to understand why they mention that we should NOT use Microsoft / Autodesk header in the Stdafx.h when _DEBUG is defined.

The never completely understood Stdafx.h & Stdarx.h fully. I know they are something to do with PCH (pre-compiled headers). But still i'm in fog.

thx

[daniel_cadext]

because, windows/Autodesk headers can include stuff like

#if defined(_DEBUG)
    #pragma comment( lib , "win_debug.lib" )
#else
    #pragma comment( lib , "win_release.lib" )
#endif

If _DEBUG is defined. you would be linking with the DEBUG CRT

it's a scope

#define _DEBUG //begin scope
// include your headers here, but nothing that may link 
#undef  _DEBUG // end scope

[ranga.narasimhan]

Thx. Yes I get that.

I thought the warning in the ObjectARX wizard had something else to it.

My understanding was that, as long as all the libraries belong to the 'same type', either debug or release, then we should be fine.

So, what is the harm in linking a debug release of an ObjectARX with a DEBUG CRT (windows / autodesk) libraries? Is there any conflict? Are we not supposed to ship our ARX files with debug CRT. I know that the ARX file size will blow up with debug libraries. Apart from this, any other problem?

-Thx

[daniel_cadext]

"My understanding was that, as long as all the libraries belong to the 'same type', either debug or release, then we should be fine."

Right, if you have a DEBUG build of AutoCAD and the ARX SDK, you should be good

[daniel_cadext · Accepted solution]

If you’re using the ARX wizard to setup your project. Then the Debug configuration isn’t really debug, more like a pseudo debug. It’s actually a release build with all the optimizations turned off and the PDB generation turned on.  _DEBUG is not defined though, and you’re still linking with the Release CRT.

You get the nice big bloaty DLL, that you can step into with your debugger and all that goodness, heck you can even ship it. You can add your own definition I.e. MY_DEBUG to put your own conditionals

"If it walks like a duck and it quacks like a duck, then it must be a duck"  its duck debug 🙂

Just don’t define _DEBUG and all your ducks will be in a row

[ranga.narasimhan]

Thanks again @daniel_cadext . I think I get it now.

Correct me if I am wrong.

If I was a autocad (aka autodesk) developer programming the actual acad.exe or allied DLLs, _DEBUG may be valid.

But since we work out of Release CRT of acad.exe, and we use still Visual Studio for ARX, it is better off not to use _DEBUG. 

As you said by using a MY_DEBUG, we have a 'local' debug build of our ARX on top on 'global' release build of acad.

Now it makes sense. 

But I wonder what will happen if I use _DEBUG in arx despite all these warnings. Let me try. LOL.

But topic closed for me as of now. Thanks again.