Take a look at this code:
#include <cassert>
#ifdef DEBUG
#define ASSERT(expr) assert(expr)
#else
#define ASSERT(expr)
#endif /* DEBUG */
The program will run only if I have DEBUG defined, otherwise it will hang and terminate with no results. I am using MinGW in Eclipse Indigo CDT. Advice is appreciated!
It's hard to tell without looking at the actual code that is causing the issue. My guess: you are evaluating an expression with side-effects within an ASSERT(). For instance, ASSERT( ++i < someotherthing ) whithin a loop. You could confirm by temporary modifying the macro definition to just expr on NDEBUG builds. After confirming this is the cause, go to each and every ASSERT call you are issuing to ensure that the expressions are side-effects free.
You are almost certainly abusing assertions. An assertion expression must never have side effects.
When you say, assert(initialize_critical_space_technology());, and then you omit this entire line in the release build, you can imagine for yourself what will happen.
The only safe and sane way to use assertions is on values:
const bool space_init = initialize_critical_space_technology();
assert(space_init);
Some people introduce a VERIFY macro for something that always executes the code:
#define VERIFY(x) (x) // release
#define VERIFY(x) (assert(x)) // debug
Related
while developing in Xcode it is common to switch between Debug and Release mode and using some parts of code in Debug mode only while not using some in Release mode.
I often throw out NSLog code by some #define rule that lets the Pre-compiler parse out those commands that are not needed in a Release. Doing so because some final testing needs proof everything works as expected and errors are still handled properly without messing some NSLog i possibly forgot. This is in example of importance in audio development where logging in general is contra productive but needed while debugging. Wrapping everything in #ifdef DEBUG is kinda cumbersome and makes code lock wild, so my #defines are working well to keep code simple and readable without worrying about NSLog left in releases while still Logging on purpose if needed. This praxis works really well for me to have a proper test scenario with pure Release code.
But this leads to compiler warnings that some variables are not used at all. Which is not much of a problem but i want to go one step ahead and try to get rid of those warnings also. Now i could turn those warnings off in Xcode but i try to find a way to keep those and just getting rid of them for my NSLog overruled #defines
So instead of logging against dev>null i throw out (nullify) all code that is wrapped by NSLog(... ) and use some extra defined rule called ALLWAYSLog() that keeps NSLog in Releases on purpose and also changes NSLog to fprintf to avoid app origin and time prints.
Here my rules..
#ifdef DEBUG
#define NSLog(FORMAT, ...) fprintf(stderr, "%s \n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String])
#else
#define NSLog(FORMAT, ...) {;}
#endif
#define ALLWAYSLog(FORMAT, ...) fprintf(stderr, "%s \n", [[[NSString alloc] initWithFormat:FORMAT, ##__VA_ARGS__] UTF8String])
To get rid of those unused variable warnings we often use
#pragma unused(variablename)
to inform the precompiler we did that on purpose..
Question:
Is it possible to write some #define rule that makes use of #pragma unused(x) ? Or how to integrate this mentioned way of __unused attribute
In the #else case, you can put the function call on the right side of the && operator with 0 on the left side. That will ensure that variables are "used" while also ensuring that the function doesn't actually get called and that the parameters are not evaluated.
#ifdef DEBUG
#define NSLog(FORMAT, ...) fprintf(stderr, "%s \n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String])
#else
#define NSLog(FORMAT, ...) (0 && fprintf(stderr, "%s \n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String]))
#endif
after testing and still not believing there is no "official way" of doing this i ended up reading my header files again. (usr/include/sys/cdefs.h)
where __unused is declared as __attribute__((__unused__)).
This seems the officially way of telling the Apple Clang (GCC) compiler a specific variable will be not used intentionally by placing a __unused directive at the right place in code. In example in front of a variables declaration or after a function declaration and more.. see stackoverflow discussion starting 2013 ongoing
#dbush 's answer was and is nice because it suppresses the unused variable warning by making use of the passed arguments and introducing nullify logic that will do no harm - but will still be executed to find "Expression result unused". That was pretty close to my goal and is possibly still the most simple solution.
in example:
#define NSLog(...) (0 && fprintf(stderr,"%s",[[NSString alloc] initWithFormat:__VA_ARGS__].UTF8String))
// applied to
int check = 333;
NSLog(#"findMeAgainInPreProcess %d",check);
// preprocesses to
int check = 333;
{0 && fprintf(__stderrp,"%s \n",[[NSString alloc] initWithFormat:#"findMeAgainInPreProcess %d",check].UTF8String);};
While this will not print anything, the compiler knows the expression is unused then.
But this left me with the question how unused marking is done properly. Trying a reciprocal approach distinguish Debug and Release to make use of __unused again in combination with my first approach like so...
#define ALLWAYSLog(...) fprintf(stderr,"%s \n",[[NSString alloc] initWithFormat:__VA_ARGS__].UTF8String)
#ifdef DEBUG
#define IN_RELEASE__unused
#define NSLog(...) ALLWAYSLog(__VA_ARGS__)
#else
#define IN_RELEASE__unused __unused
//#define NSLog(...) (0&&ALLWAYSLog(__VA_ARGS__)) //#dbush solution
//#define NSLog(...) NSCAssert(__VA_ARGS__,"")
//#define NSLog(...) {;}
#define NSLog(...) /*__VA_ARGS__*/
#endif
In Debug it will not silence the unused variable warning by parsing out the directive itself and in Release it will exchange IN_RELEASE__unused to __unused according to the macro and silence it. This is a little extra work but could help to see which parts are unused on purpose.
Means i can type like below..
IN_RELEASE__unused int check = 333;
NSLog(#"findMeAgainInPreProcess %d",check);
// produces for DEBUG
int check = 333; //no warning, var is used below
fprintf(__stderrp,"%s \n",[[NSString alloc] initWithFormat:#"findMeAgainInPreCompile %d", check].UTF8String);
// produces for RELEASE
__attribute__((__unused__)) int check = 333; //no warning intentionally
; // no print, nothing
This keeps NSLog in place (in code), marks the unused variables to silence the warning properly and NSLog gets parsed out completely in Release. And i can still force prints for both modes with the introduced ALLWAYSLog.
Conclusion: dbush's solution is still more straight forward.
Currently using to show debug output when in debug mode:
#ifdef _DEBUG
#define printX(...) Serial.printf( __VA_ARGS__ )
#else
#define printX(...) NULL
#endif
yet this still include the printX in the result code, and the parameters which have been applied still consume memory, cpu power, and stack size, so my question is:
is there a way to have a macro, which is not including the function, and "ignoring" all of it's calls in the source when in "release mode" and basically not compile anything with it ?
A macro is a not a function. It does not consume any memory, cpu power, or stack size. This is because macros operate entirely at compile time, and just act as a text replacing mechanism. When the program is run, there are no macros which are "called".
The macro
#define printX(...) NULL
replaces printX function call with all its arguments with plain NULL. This is a textual replacement that happens before a compiler is able to take a look at the code, so any nested calls inside printX, e.g.
printX(someExpensiveCall())
will also be completely eliminated.
In my programs I include a line that says:
#define DEBUG_MODE
and I use it anywhere I want to compile with (or without) debug mode:
#ifdef DEBUG_MODE
print here all the info I need for debug and certainly don't want in released binary.
#endif
Before releasing the final binary I comment out the definition line.
I've noticed that some code often looks like this:
#ifdef DEBUG
assert(i == 1);
#endif //DEBUG
and that you may have several blocks of these sitting around in your raw code. Having to write out each block is tedious and messy.
Would it be plausible to have a function like this:
auto debug_assert = [](auto expr) {
#ifdef DEBUG
assert(expr);
#endif //DEBUG
};
or something like this:
#ifdef DEBUG
auto debug_assert = [](bool expr) {
assert(expr);
};
#else //DEBUG
void debug_assert(bool expr) {}
#endif //DEBUG
to get a zero-cost assert when the DEBUG flag is not specified? (i.e. it should have the same effect as if it was not put into the code without the lambda running, etc. and be optimized out by the g++/clang compilers).
As mentioned by #KerrekSB, you can already disable asserts by defining NDEBUG before including <cassert>. The best way to ensure that it's defined before including the header file is to list it in as the argument to the compiler (with gcc it's -DNDEBUG)
Note: the assert is removed by replacing it with a no-op expression, and there, the argument isn't evaluated at all (which is different from your suggested solution)! This is why it's of utmost importance to not call any functions that have side effects in assert.
For completeness: here is how assert can be implemented:
#include <cstdio>
#include <cstdlib>
#ifndef NDEBUG
#define assert(EXPRESSION) ((EXPRESSION) ? (void)0 : (printf("assertion failed at line %d, file %s: %s\n", __LINE__, __FILE__, #EXPRESSION), exit(-1)))
#else
#define assert(EXPRESSION) (void)0
#endif
Introducing your own assert-style macro is very commonly done. There are quite a lot of reasons you may want to do this:
you want to include more information about the evaluated expression (see Catch's REQUIRE and how they use expression templates to decompose the expression into individual elements and stringify them)
you want to do action other than exit()ing the program, like throwing an exception, mailing the developer, logging to a file, breaking into the debugger
you want to evaluate the expression even on release builds which is less error prone than not evaluating it at all (after all, if it doesn't have side effects, it can be eliminated by a compiler optimizations, and if it does, you just avoided a heisenbug)
and so on, and so on (if you have an idea, you can post a comment, I'll add it to the answer)
I want to realize this behavior:
When program runs in debug mode, assert_robust(expression, commands) works strictly like classical assert(expression)
When program runs in release mode, assert_robust(expression, commands) perform some commands if expression is false
This can be done this way:
#ifdef NDEBUG
#define assert_robust(expression, command) if (!(expression)) command;
#else
#define assert_robust(expression, command) assert(expression);
#endif
And this can be used for example this way to make myfunction fault-tolerant:
char myfunction(const string& s, int i)
{
assert_robust(i >= 0, return '\0');
/* Normal code */
}
This work well, but how to make macro assert_robust that supports more than one (arbitrary) number of commands? (preferably by a standard C++ way)
And another question is:
Is it good thing to be strict in debug and benevolent in release?
EDIT: My idea why do such a thing is because it is practicaly much better if it is a bug in the program that the program maintains sometimes a little weird than when it crashes and user losing their data.
The more interesting question is the second:
Is it good thing to be strict in debug and benevolent in release?
My experiences is that it is a horrible idea to have different behavior in debug and release builds. You are signing up for issues in production that you will never be able to reproduce in a debug build because the behavior of the two is different.
Other than that, which you may claim won't be an issue if you assert in the first place in debug mode, asserts should be used to flag programming issues, situations from which you cannot recover safely. If you can recover safely in release mode, why assert in DEBUG? If you cannot, are you willing to fiddle with production data in a way you don't quite understand what it will do?
Without getting into the issue of if this is a good idea or not, you can use your macro to wrap multiple commands in a do-while(0); loop.
#ifdef NDEBUG
#define assert_robust(expression, command) if (!(expression)) \
do{command;} while(0)
#else
#define assert_robust(expression, command) assert(expression)
#endif
Note also that I did not include semicolons at the ends of the macros. If you include them in the macros, then something like
assert_robust(cond1, command1) /* no semicolon here, no problem */
assert_robust(cond2, command2) /* no semicolon here, no problem */
would be allowed, which would be really weird.
I don't think to use assertions this way is a good idea. Usually you use an assert, if you want the predicate to be always true, because its part of critical code. If its not true, than there is obviously a big problem and aborting is reasonable. But more and more people use assert like an ordinary error check for debugging. In this case its adequate to disable it completely in release mode. It think you should decide for one of this two approaches.
But if you want to run some kind of emergency commands before aborting, you could use the new lambda functions from C++11:
void ASSERT(int expression, std::function<void()> func) {
if(!expression) {
if (func) func();
abort();
}
}
You could use it like this:
ASSERT(a >= 0, []() { std::cerr << "ERROR" << std::endl;});
Or:
ASSERT(a >= 0, [this]() { this->terminate(); });
Or:
ASSERT(a >= 0, nullptr);
My coworker just asked me to help on a problem, he has a few lines in his code as
for (long counter = 0; counter < End; )
{
...
assert(counter++ < MAX);
...
}
The problem is, when we use Visual Studio to debug line by line, seems the assert() line got skipped all the time, and counter never got incremented and thus the loop never finished.
When we look at the disassembly using VS, there is no assembly line for this assert() function. I never used assert() before, so I'm wondering is this normal and he shouldn't put any code behavior into assert() or something is wrong here with debugger or other?
Thanks.
Make sure that NDEBUG is not defined, as assert is enabled only in debug build, i.e when NDEBUG is not defined.
From here:
#ifdef NDEBUG
#define assert(condition) ((void)0)
#else
#define assert(condition) /*implementation defined*/
#endif
That is, when NDEBUG is defined, assert is no-op which is what you observe in assembly.
You should only use assert for debugging purposes.
The line
assert(counter++ < MAX);
contains logic, and it shouldn't.
In a non-debug build, it will never be executed.
assert is a macro, which is removed in release builds. So unless you're looking at a debug build, don't expect to see any assert code.
And because assert is a macro, and not a function, it's not likely to look like a single function call either.
If the code is built under Release Mode, the assert statements will not be included. Is your coworker using Release Mode?
Visual Studio's optimization settings may also remove the assert statements.
Couldn't your coworker change the for loop to not use the assert statement?
Asserts typically get removed from release builds and therefore are executed only for debug builds. You should never have any side effects affecting program logic in assert.