I need to only run ship build and I need to assert on certain condition in release build to see if the problem is fixed. How do I do it?
+4
A:
Undefine the NDEBUG macro - you can do this locally around the asserts you want to remain in the build:
#undef NDEBUG
#include <assert.h> // reinclude the header to update the definition of assert()
or do whatever you need to do so your build process does not define the NDEBUG macro in the first place.
Michael Burr
2009-03-06 23:44:32
if the assert.h included in the pch file, it might won't work.
lz_prgmr
2009-03-07 00:33:51
I've just tried it -- it does not always work. If I put this as a first two lines in my .cpp it does not do anything, it works though when I put it just above my main().
mezhaka
2009-12-13 19:37:21
Then it seems that something must be redefining NDEBUG and including `assert.h` again (possibly some other header that's being included).
Michael Burr
2009-12-13 23:15:33
A:
The default behaviour of ASSERT is to abort the program under the Debug configuration, but this generally becomes a no-op under a Release configuration. I believe it does this by checking for the existence of the preprocessor NDEBUG macro. I'm not at work at the moment so cannot check this.
I think the easiest way around this is to modify the Debug configuration to turn all optimisations up to the same level as Release (O2 from memory), and then re-build your software. This will give you the equivalent performance and speed of a Release build, but it will still define the NDEBUG preprocessor macro which means all failed ASSERTs will still cause the program to abort. Just remember to change the optimisation level back later, otherwise you will have trouble debugging under the Debug configuration.
In general though, ASSERTs should only be used for programming preconditions and never to handle failures in shipping software. You want to fail quickly during development, but gracefully in front of a user.
LeopardSkinPillBoxHat
2009-03-06 23:48:12
+7
A:
Why not just define your own assert:
#define assert(x) MessageBox(...);
lz_prgmr
2009-03-07 00:36:15
Up voted because its the only sain suggestion here. Though recommend putting a line number and also the explanation of what went wrong. Though the next thing is also to design your own crash system so when an assert it hit, that you do a memory dump that is automatically sent off to you.
Chad
2009-09-28 02:13:42
+1
A:
Just call directly the part of the assert macro definition that is active in release mode.
You can find very useful definitions for assertions in C++ in this great article by Miro Samek. Then you can tweak them a bit to satisfy your needs. For example, you might create another macro, release_assert, that does the same as assert but regardless of whether it's in release or debug mode.
Daniel Daranas
2009-03-10 08:51:07
A:
I like to define it to throw some sort of assert_exception derived from a std::runtime_error. Then catch it somewhere and do something useful.
Zan Lynx
2009-05-15 04:12:15
A:
Actually - I'd go with shipping the debug version if you can live with it. If you don't need the performance of the release version, use the debug. It tend's to have fewer bugs (this is a gross oversimplification and if you program is free of bugs, just switching to release does not change this, but due to things the compiler does in debug mode, the bugs may not occur and/or have less severe consequences).
Perhaps it is also possible to optimize only the time critical parts of you program.
It can also simplify debugging.
Tobias Langner
2009-09-28 13:04:32