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.
Related
I am working with emscripten, which uses some macros that VS Code IntelliSense does not like. This is not unusual. So what I'd like to do is this:
#ifdef INTELLISENSE_IS_READING_THIS
#define PROBLEMATIC_MACRO
#endif
That way, I can keep the macros as is but VS code will stop whining.
Sad thing is I remember solving this exact problem in Visual Studio 2017 IntelliSense - with Microsoft's very own resource files - but unfortunately, it appears I did not ask this on stack overflown and instead solved it myself, so now I can't find it anymore.
𝙃𝙖! Found it. Just needed to craft a query that excludes all the questions about IntelliSense NOT reading or defining defines.
This is the way:
#ifdef __INTELLISENSE__
#define EMSCRIPTEN_KEEPALIVE
#endif
And this also works, but may also evaluate in Microsofts compiler:
#ifdef _MSC_VER
#define EMSCRIPTEN_KEEPALIVE
#endif
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
I am doing my school assignment. During debug mode I would like to turn on my console mode and during release turn off console.
I have try marco as recommended in stackoverflow but it is not working. I am using visual studio 2012 (empty project c++)
#if DEBUG
//doing something
#else
//Release mode doing something
#endif
#if DEBUG will only work if you define DEBUG via the compiler options.
By default, DEBUG is not defined, but _DEBUG is. Try #if defined(_DEBUG), or change your compiler options (via Project Properties / Configuration Properties / C/C++ / Preprocessor / Preprocessor Definitions) to define DEBUG.
#if DEBUG will resolve itself at compile time not at run time.
NDEBUG is pretty standard macro defined in release mode.
And I think Visual studio defines _DEBUG macro when in debug mode.
In any case you can define your own macros in Visual Studio
Go to Project->Properties->Configuration Properties->C/C++->Preprocessor -> Preprocessor Definitions There you can add macros for your project in the build configuration you have chosen.
From your comments it seems that tproblem you're running into is getting a console window open and connected to stdout (having little to do with DEBUG vs. RELEASE builds).
See the MS Support Article INFO: Calling CRT Output Routines from a GUI Application for a working example of how to have a GUI program open a console and direct stdout to it:
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
// ...
int hCrt;
FILE *hf;
AllocConsole();
hCrt = _open_osfhandle(
(long) GetStdHandle(STD_OUTPUT_HANDLE),
_O_TEXT
);
hf = _fdopen( hCrt, "w" );
*stdout = *hf;
int i = setvbuf( stdout, NULL, _IONBF, 0 );
puts("hello world");
Actually, on further testing, your simpler technique of using freopen("CONOUT$","w",stdout); works too. For some reason in my initial tests it didn't seem to work. You may need to also have the setvbuf() call to avoid buffering problems.
This is for Visual studio 2019:
#ifdef _DEBUG
// do something in a debug build
#else
// do something in a release build
#endif
For C# the constants DEBUG works fine, Just make sure that in the project properties it is enabled.
Go to project properties (by right clicking on your project in solution explorer), then select build option on right side of the window and check the define DEBUG constant checkbox.
Then you can use code like this.
#if DEBUG
// debug mode
#else
//release mode
#endif
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.
I am trying to migrate existing c++ 32 code to 64 code on windows7 with visual studio 2010.i never did 64bit compilation before. with the help of internet references i did the setup for 64 bit compilation. like VS2010 with 64 bit compiler etc and other configuration changes.
In the preprocessor i removed WIN32 and added WIN64. i have some other pre-processors like OS_WIN_32 and some other which are specific in my code.
In the code wherever WIN32 was getting used i added extra condition as || WIN64 this is just to ensure that application should get compiled with win32 as well as win64.
When i am trying to compile the code i am getting the compilation error saying
fatal error C1189: #error : Only one of the WIN32 and WIN64 symbols should be defined
this error is coming from the local code where we have a check whether both WIN32 and WIN64 are defined. that code is as shown below.
#if defined WIN32 && defined WIN64
# error Only one of the WIN32 and WIN64 symbols should be defined
#endif
in VS2010 if macros are not enabled then the code inside the macro gets greyed out. in my code also the above error is greyed out. but still i am getting that error.
The code where i added WIN64 is including windows.h. for reference givine it below.
#if defined WIN32 || defined WIN64
#include <windows.h>
#include <process.h>
#endif
So my question is why i am getting this error? shouldnt we add windows.h for 64bit compilation.? i tried by commenting this inclusion but i am getting other errors wrt HANDLE which are used in the code.
If i go to WIN32 definition VS2010 is pointing to a definition in windef.h file. This file is present in Microsoft SDKs\windows\v7.0A\include folder i.e. not my local code.
for referance that definition is given below.
#ifndef WIN32
#define WIN32
#endif
So i want to know why compiler is getting both pre-processors WIN32 and WIN64.
Thanks in advance for your help.
You shouldn't define either yourself. The macro's that should be used to check this are
_WIN32 // always defined for Windows apps
_WIN64 // only defined for x64 compilation
These are defined by the compiler (see here).
Often, the IDE adds the unprefixed macros to the commandline to not let legacy projects which use the non-documented unprefixed versions fail to build. The fact that they work is not a reason to use them, when documented alternatives are present.
It boils down to this:
#ifdef _WIN32
// We're on Windows, yay!
#ifdef _WIN64
// We're on x64! Yay!
#else // _WIN64
// We're on x86 (or perhaps IA64, but that one doesn't matter anymore). Yay!
#endif // _WIN64
#else // _WIN32
// We're not on Windows, maybe WindowsCE or WindowsPhone stuff, otherwise some other platform
#endif