I've Win32 DLL application. Debug build is selected. I wrote such code:
#if DEBUG
fflush(logFile);
#endif
But fflush(logFile); is grayed out so I assume it will not be executed.
But i want it to be executed. Does it mean that in Debug DEBUG symbol is not defined? Where can I define it in VS2012?
Preprocessor definitions are defined under project settings as shown on screenshot (note _DEBUG there):
Note that in case of _DEBUG you want to check if it is defined at all, and not compare it (possibly missing definition) to zero. You want:
#if defined(_DEBUG)
or
#ifdef _DEBUG
By default, a Visual Studio C++ project will have the macro _DEBUG defined for a Debug project configuration. It will have the value 1, so you can test for it using #if or #ifdef.
But note that the macro starts with an underscore - if you want to use the name DEBUG (maybe you have existing code that uses that name), you'll need to add it to the project properties yourself (C/C++ | Preprocessor | Preprocessor definitions). Or you can put the following in a header that's included in every translation unit (maybe stdafx.h):
#if _DEBUG
#undef DEBUG
#define DEBUG 1
#endif
Every project has two builds: Debug and Release. Debug build have DEBUG defined, as if you defined using:
#define DEBUG
It enables, the code to get generated differently. The writers of code (functions, classes etc), may add additional diagonistics to aid in debugging. The Debug build is for debugging only, and you don't give this build (i.e. EXE generated with Debug build), to the customers.
Another build where DEBUG symbols is not defined, is for Release build. A release build is for optmized code, at code level, compiler setting level, and linker level. Most of diagonistic, asserts, debugging-aid feature will be disabled - so as to produce optimized executable.
Whomsoever who has written the above code, has written the same thing in mind. To let flush the file, only if debug build is running. You can comment the #if and #endif, and let fflush line compiled, or you can use Release build. It all depends on you.
Related
I am using Android Studio 3.0 for my NDK based app.
For the C++ code, I use CMake as the external builder.
This works well, I can create debug and release binaries.
However, I would like to turn on compiler optimizations (say -O3) for a part of the C++ code (the physics engine), not just for the release build, but also for the debug build.
So create the bulk of the debug build as is, without optimizing, yet, I want one of the static library targets to be built with the compiler optimization enabled.
How can I go about this?
I have a CMakeLists for a static library target that gets included using add_subdirectory() directive in the top level CMakeLists file.
Note that I point to the top level CMakeLists in my app's build.gradle file like this:
externalNativeBuild {
cmake {
path '../../Android/jni/CMakeLists.txt'
}
}
It turns out that you can use the target_compile_options() macro in your CMakeLists.txt with a config specification like this:
target_compile_options(opende PRIVATE
"$<$<CONFIG:RELEASE>:-O3>"
"$<$<CONFIG:DEBUG>:-O3>"
)
This macro adds to the existing compile options.
I have a fairly simple, multithreaded application that runs as a console app in c++, based mostly on calling external dlls. I need to add a Form to it, so I have created a new visual studio project (c++/CLR), and am adding my existing cpp and .h files to it. BUT, when I try to build, i get:
Severity Code Description Project File Line Suppression State
Error C1189 #error: <thread> is not supported when compiling with /clr or /clr:pure.
Severity Code Description Project File Line Suppression State
Error (active) #error directive: <mutex> is not supported when compiling with /clr or /clr:pure.
IS this how I should be adding a form? How can I get around this error?
Thanks.
Ah, solved. As here:
VC2008, how to turn CLR flag off for individual files in C++/CLI project
I need to turn off clr support on the single .cpp file.
I need my application to be upgraded from visual studio 2005 IDE to visual studio 2012 .
The upgradation wizard converts the solution and project files successfully with 0 errors and few warnings.
But when i start building the application i get error message :
error C1189: #error : This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended. in atlcore.h !
I tried changing the version no to 0x0500 , 0x0501 , 0x0502 and also 0x0601 ( both through /D compiler option and manually changing in atlcore.h , WINVER is also changed. ) but no luck . the same error is being displayed.
Where do i go wrong ?
Visual C++ no longer supports targeting Windows 95, Windows 98, Windows ME, or Windows NT. If your WINVER or _WIN32_WINNT macros are assigned to one of these versions of Windows, you must modify the macros.
To modify the macros, in a header file, add the following lines.
#define WINVER 0x0500
#define _WIN32_WINNT 0x0500
EDIT:
WINVER determines the minimum platform SDK required to build your application, which in turn will determine at compile time which routines are found by the headers.
#define _WIN32_WINNT_NT4 0x0400
#define _WIN32_WINNT_WIN2K 0x0500
#define _WIN32_WINNT_WINXP 0x0501
#define _WIN32_WINNT_WS03 0x0502
#define _WIN32_WINNT_WIN6 0x0600
#define _WIN32_WINNT_VISTA 0x0600
#define _WIN32_WINNT_WS08 0x0600
#define _WIN32_WINNT_LONGHORN 0x0600
#define _WIN32_WINNT_WIN7 0x0601
Other Solution:
If you have installed a WIndows SDK on your PC (in /Microsoft SDKs/Windows), you can #include in stdafx.h (or in a header you include in all your C++ files). Including SDKDDKVer.h will target the highest Windows version available.
Hopefully It work!!!!!
For more info SEE HERE
Problem temporarily solved by commenting a check in atlcore.h :
if _WIN32_WINNT > 0x0501
//#error This file requires _WIN32_WINNT to be #defined at least to 0x0403. Value 0x0501 or higher is recommended.
endif
I know it isnt the right way to do [ editing a file shipped by the IDE ] but did since it may be due to Improper installation.
If anyone come across a permanent fix let me know .
you can add a pre-processor directive for the project under project settings, C/C++, Pre-processor definitions, appending WINVER=0x0501;
(you can also undefine definitions)
I'm wondering if you are using pre-compiled headers which is overwriting changes to stdafx.h, this is the way to make sure this is set
This preprocessor setting holds until code in the project files changes it, at which point if this doesn't fix the problem, then you must find how or where this is being set/unset/checked; but the solutions shouldn't involve any changes to the windows SDK files
This is part of a series of at least two closely related, but distinct questions. I hope I'm doing the right thing by asking them separately.
I'm trying to get my Visual C++ 2008 app to work without the C Runtime Library. It's a Win32 GUI app without MFC or other fancy stuff, just plain Windows API.
So I set Project Properties -> Configuration -> C/C++ -> Advanced -> Omit Default Library Names to Yes (compiler flag /Zl) and rebuilt. Let's pretend I have written a suitable entry point function, which is the subject of my other question.
I get two linker errors; they are probably related. The linker complains about unresolved external symbols __fltused and _memcpy in foobar.obj. Needless to say, I use neither explicitly in my program, but I do use memcpy somewhere in foobar.cpp. (I would have used CopyMemory but that turns out to be #defined to be identical to memcpy...)
(I thought I could get rid of the memcpy problem by using a compiler intrinsic, like #pragma intrinsic(memcpy), but this makes no difference.)
If I look at the preprocessor output (adding /P to the compiler command line), I see no references to either __fltused or _memcpy in foobar.i.
So, my question is: Where do these linker errors come from, and how do I resolve them?
__fltused implies you are using or have at least declared some floats or doubles. The compiler injects this 'useless' symbol to cause a floating support .obj to get loaded from the crt. You can get around this by simply declaring a symbol with the name
#ifdef __cplusplus
extern "C" {
#endif
int _fltused=0; // it should be a single underscore since the double one is the mangled name
#ifdef __cplusplus
}
#endif
WRT _memcpy - memcpy is a __cdecl function, and all cdecl functions get an automatic _ as part of their decoration. so, when you say "__cdecl memcpy" - the compiler & linker go looking for a symbol called '_memcpy'. Intrinsic functions - even explicitly requested - can still be imported if the build settings have debug settings that contra-indicate intrinsics. So you are going to need to implement your own memcpy and related functions at some point anyway.
I recommend setting the "generate assembly listing" (or some such) compiler option for foobar.cpp once, and then inspecting the assembler code. This should really tell you where these symbols are used.
I am trying to maintain a program written 5 years ago in VC++ 6.0. It uses our 'common' libraries. The trouble I have is that it either links against the debug version of these libraries or the Release version, depending on whether I have the [Directories] for [library files] set to "common/debug" or "common/release" in [Tools]->[Options].
How do I get it to link to [common\debug\common.lib] when building the debug version and [common\release\common.lib] when building the release version? If I have both paths in the library directories, it seems to link to the first one it finds.
Instead of specifying the paths in the include folders and all the best way i use to include the libraries depending on the configuration is by using #pragma
try this once, it is very useful
#ifdef _DEBUG
#pragma comment(lib, "..\\DllTest\\Debug\\DllTest.lib")
#else
#pragma comment(lib, "..\\DllTest\\Release\\DllTest.lib")
#endif
In [Project Properties]->[Linker]->[Input]->[Additional Dependencies] you can use the $(ConfigurationName) placeholder, like this:
c:\common\$(ConfigurationName)\common.lib
In the Debug configuration this will change to:
c:\common\Debug\common.lib
and in Release it will change to:
c:\common\Release\common.lib
If I have both paths in the library directories, it seems to link to the first one it finds.
Just add the debug folder for the debug settings and the release folder for release settings.
Almost all compiler, linking etc. settings are per configuration (the project properties will show settings as blank in "all configurations" (if I recall the right text) if debug and release are different.
You could specify the full path of the library to link to in the Additional Dependancies field, this can have different values for debug and release builds.
The solution I have found is a little like Richard's & "1800 Information"'s...
I removed the Common library path from Tools->Options. The paths in here are global to all configurations of all projects running in MSVS VC++ 6.0.
I then added a full path to the appropriate library in Project->Settings for each configuration. Hense the debug configuration has D:\VSS\Common\Debug\Common.lib and the release configuration has D:\VSS\Common\Release\Common.lib. This seems to work and for the first time I have no build warnings!
Thanks to all the suggestions for pointing me in what seems to be the right direction.
--- Alistair.