I have C++ code with asserts. When I compile the code with g++ -D NDEBUG option no assert commands are executed. But when I include NDEBUG on the code #define NDEBUG and compile it with no -D NDEBUG option, assert command are executed. How to disable asserts without changing command line?
You have to define NDEBUG before including the header that defines assert. Try
#define NDEBUG
#include <assert.h>
at the top of the source file you want to disable assertions in.
By defining NDEBUG. In practice, you would never compile with
-D NDEBUG in the command line; you should define your own
debug command, and then when the profiler shows you cannot
afford the checks in a specific function, wrap the function in
something like:
// Non-critical code...
#ifdef MYDEBUGOFF
#define NDEBUG
#endif
#include <assert.h>
// Critical function
#undef NDEBUG
#include <assert.h>
// More non-critical code.
You can include <assert.h> as often as you like; each time it
redefines the assert macro according to whether NDEBUG is
defined at that moment. So you can tune to your heart's
content; just #define NDEBUG or #undef NDEBUG each time
before you include the header.
Related
In the link below the C++ code's comments it says;
// and compile with -DPSAPI_VERSION=1
https://learn.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-enumprocessmodules
How do we compile with -DPSAPI_VERSION=1 ?
Two possibilities
just before the include of windows.h add
#define PSAPI_VERSION=1
or in the project properties there is a place to define macros, add PSAPI_VERSION=1 there
Macros are defined in the program. I usually define a macro in the cmake file as a switch. Then in the program, if the macro is found to be defined, the algorithm library call is executed, because my algorithm library is sometimes not configured properly.
CMakeLists.txt
add_definitions(-DRecognitionLIB")
in cpp file
#ifdef RecognitionLib
#include <GBProcess.h>
#include <AIScrapperVision.h>
#endif
function aaa()
{
#ifdef RecognitionLib
some code
#endif
}
My current goal is to create one (or as few as possible) line of code that will switch the remainder of the active compilation unit to an unoptimized, debug configuration. My first instincts were either:
FORCE_DEBUG;
// code below here will be forced to be unoptimized and in a debug environment
or
#include "ForceDebug.h"
// code below here will be forced to be unoptimized and in a debug environment
would be ideal. In my workspace, to convert to an unoptimized debug configuration requires I change the pragma optimize level, but also #undef some macros and #define other macros.
The FORCE_DEBUG macro doesn't work because it would need to execute preprocessor directives #undef and #define which I understand are not evaluatable within a macro.
Instead I have a working version of #include "ForceDebug.h". But I want to message the developer that they have disabled optimization on a given compilation unit (so they don't check it in, or if they do check it in that it can be caught and fixed). Ideally this message includes the filename of whichever file #includes "ForceDebug.h" or the current compilation unit.
Here's an approx ForceDebug.h
#pragma once
#pragma message("DISABLING OPTIMIZATION IN" COMPILATION_UNIT_FILE)
#undef _RELEASE
#define _DEBUG
#ifdef _MSC_VER
# pragma optimize("", off)
#else
# pragma GCC optimize("O0")
#endif
So a call site would look something like Foo.cpp:
// this messages "ForceDebug.h", I want to message "Foo.cpp"
//#define COMPILATION_UNIT_FILE __FILE__
// double macro also messages "ForceDebug.h"
//#define COMPILATION_UNIT_FILE COMPILATION_UNIT_FILE2(__FILE__)
//#define COMPILATION_UNIT_FILE2(x) x
// this works but requires doing it manually, which I'm trying to avoid
#define COMPILATION_UNIT_FILE "Foo.cpp"
#include "ForceDebug.h"
// code below here will be forced to be unoptimized, debug environment
I can't use __FILE__ because that messages about ForceDebug.h, when I want it to report about Foo.cpp.
If I could evaluate __FILE__ inside Foo.cpp and pass the evaluated version into ForceDebug.h that would be acceptable, but I tried recursive macro calls and it still reported ForceDebug.h
Is there any way to get it to pass "Foo.cpp" into the include or to derive that value by some other means for either clang or Visual Studio?
I was not able to find a way to emit the current compilation unit name from an included file.
However, your proposed syntax requires the user of "ForceDebug.h" to add another directive to expose its compilation unit name to the header file. Instead, you can turn it around and allow simple inclusion that defines a macro that allows for the message to be emitted.
While, generally speaking, macros cannot be used to generate pre-processor directives, there is a syntax for pragmas for the compilers you illustrated. MSVC and GCC each have their own syntax, but conditional compilation can make the syntax appear uniform.
In your source file:
#include "ForceDebug.h"
FORCE_DEBUG;
//... rest of source
In "ForceDebug.h":
#pragma once
#ifdef _MSC_VER
#define DO_PRAGMA(X) __pragma(X)
#define NO_OPT optimize("", off)
#else
#define DO_PRAGMA2(X) _Pragma(#X)
#define DO_PRAGMA(X) DO_PRAGMA2(X)
#define NO_OPT GCC optimize("O0")
#endif
#define FORCE_DEBUG \
DO_PRAGMA(message("DISABLING OPTIMIZATION IN " __FILE__)) \
DO_PRAGMA(NO_OPT) \
struct __force_debug
#undef _RELEASE
#define _DEBUG
You could use the __FILE__ predefined macro like below:
#pragma message("DISABLING OPTIMIZATION IN " __FILE__)
Live Demo
Edit:
Since you want to report about the .cpp file I would go the other way around. That is, I would change ForceDebug.h to:
#pragma once
#undef _RELEASE
#define _DEBUG
#define OPT_OFF
^^^^^^^^^^^^^^^
#ifdef _MSC_VER
# pragma optimize("", off)
#else
# pragma GCC optimize("O0")
#endif
And then I would put the potensial message in my .cpp file:
#include "foo.h"
...
#ifdef OPT_OFF
#pragma message("DISABLING OPTIMIZATION IN " __FILE__)
#endif
Motivation:
I want to enable the memory detection of VC++, which requires that some statements must be at the forefront as follows:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Question:
Suppose I have a header file forefront.h, what I want is the following effect:
a.cpp
#include <any_other_one.h>
#include <forefront.h> // An compiler error generated here!
b.cpp
#include <forefront.h> // OK
#include <any_other_one.h>
How to implement?
Create your own header file with the following contents:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Now use the Forced Includes setting in the Advanced section of the project's settings. Any file specified there will be included before all others, in the order specified.
Since what you're really asking is how to ensure _CRTDBG_MAP_ALLOC is defined in all compilation units, use the VC++ project system to add that definition. Go to the project properties dialog, and in the C++ Preprocessor section add _CRTDBG_MAP_ALLOC to the Preprocessor Definitions line.
I think this is the most non-intrusive solution I come up with,
put the following at the beginning of forefront.h,
#if (__LINE__ != 0)
#error ERROR_FORE_FRONT_IS_NOT_THE_FIRST_TO_INCLUDE
#endif
you don't need to change others.h.
I tested this code with GCC 4.6.3.
I guess something like this might work:
other.h
#ifndef OTHER_H_
#define OTHER_H_
...
#endif
forefront.h
#ifdef OTHER_H_
#error Wrong include order
#endif
In .cpp file I use a macro mmData1.I searched in the project and see that this macro is defined in several files.(I.e. there are several .h files which have the line #define mmData1)
I want to know if there is a capability in VS10 to check from which file the preprocessor takes the macro value
If Intellisense does not know then there is no direct way. However, there are indirect ways. Say your macro name is SOME_MACRO
After each instance of #define SOME_MACRO put #error Defined here, then right click the source file and choose Compile. If compiler returns an error remove the directive that raises it and compile again. The last instance of this error will tail the definition visible in the source.
Make each directive defining SOME_MACRO define it as something else and then, in the source file, add these lines after all includes:
#define STRINGIZE(x) STRINGIZE2(x)
#define STRINGIZE2(x) #x
#pragma message("SOME_MACRO is expanded as: " STRINGIZE(SOME_MACRO))
Compile the source file; you should see the value in the build log.
Less intrusive way: put those lines after each #define SOME_MACRO
#pragma push_macro("STRINGIZE")
#pragma push_macro("STRINGIZE2")
#define STRINGIZE(x) STRINGIZE2(x)
#define STRINGIZE2(x) #x
#pragma message("Defining at " __FILE__ ":" STRINGIZE(__LINE__))
#pragma pop_macro("STRINGIZE")
#pragma pop_macro("STRINGIZE2")
Or, if you don't need the line number:
#pragma message("Defining at " __FILE__)
Compile the file. Looking at build log you should be able to tell the order of SOME_MACRO definitions.
The best way to see exactly what the preprocessor is doing is to inspect its output directly. Intellisense is helpful but often does not match what the compiler understands.
A simple trick I always use is to redefine the macro at the line you want to check. When you compile the code, the preprocessor will complain and tell you where the previous definition was.
Example:
test.cpp contains:
#include "test.h"
int main()
{
#define SOMEMACRO 1
return 0;
}
test.h contains:
#define SOMEMACRO 2
int foo();
when compiling test.cpp, I get this error message:
test.cpp:5:0: warning: "SOMEMACRO" redefined [enabled by default]
In file included from test.cpp:1:0:
test.h:1:0: note: this is the location of the previous definition
I tested on GCC, but Visual Studio does the same thing.
In an MSVC C++ program I have a part of code which I want to enable or disable depending on a preprocessor definition
// 1.h
#ifdef MYOPTION
//...
#endif
But I find that it is quite dangerous when it is used in a .h file included in more than one compilation unit, as I can easily get inconsistent headers (I don't want to define MYOPTION globally as it would require a complete recompilation each time I change it):
// 1.cpp
#define MYOPTION
#include "1.h"
// 2.cpp
#include "1.h"
Of course, it is much more complicated than this simplified example due to the chained header inclusion.
Is there a way to avoid such inconsistency, e.g. have a compile-time error without too much effort?
I thought of doing #define MYOPTION 0 or 1, but then I would have to write something like
#if MYOPTION == 1
//...
#elif !defined(MYOPTION)
#error ...
#endif
which looks too complicated... Maybe there is a better option?
How about something like this: have 1.h define a dummy section in the obj with different options. This way, if MYOPTION is ever used inconsistently, the linker will issue a warning.
1.h:
#ifdef MYOPTION
#pragma section("MYOPTION_GUARD",write)
#else
#pragma section("MYOPTION_GUARD",read)
#endif
namespace { __declspec(allocate("MYOPTION_GUARD")) int MYOPTION_guard; }
Compiling with MYOPTION defined in a.cpp but not in b.cpp yields this linker warning (using VC 2008):
b.obj : warning LNK4078: multiple 'MYOPTION_GUARD' sections found with different attributes (40300040)
A consistent definition yields no linker warnings at all.
I think you've listed most solution yourself, basically. I would use the last solution, but perhaps in a slightly different form:
#ifndef MYOPTION
#error ...
#endif
...
#if MYOPTION == 1
//...
#endif
Because often this #if MYOPTION == 1 will appear more than once in each file. It's also clearer that MYOPTION is a requisite for that file.
You say it "looks too complicated", but I'm afraid there's probably no solution that's less "complicated" than this.
Assuming that you actually need to use the defines, better is to define them via the compiler command line than #define in your source files. Then your configure script/makefile/build process sets the define once and you're guaranteed that it will agree properly across all source files.
Perhaps what you want is to create a separate configuration.
You can go to Build -> Configuration Manager and create a new configuration (separate from DEBUG, RELEASE). Creating a new configuration will allow you to define preprocessor symbols specific to that configuration.
For example, with a new configuration titled "MyOption 1" you could add the preprocessor definition MYOPTION = 1. The same thing goes with MYOPTION = 2, 3, ...
Each configuration has to be built separately.
DEBUG and RELEASE are examples of separate configurations; DEBUG defines _DEBUG and RELEASE defines NDEBUG