29

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?

Chad
  • 2,938
  • 3
  • 27
  • 38
  • What platform? Windows and Visual Studio? – Peter Mortensen Sep 28 '09 at 13:47
  • It is generally not recommended to keep assertions in Release builds. However you may have a good reason to do so; still, it may also not be called "assertion" and in this case it should not use the same function calls. – moala Feb 02 '12 at 18:16
  • Why not use a simple condition instead? Think about what your program should do if the "assertion" fails. You should not just call `std::abort` in a release build. If you are developing an application, throw an exception. If you are developing a library, provide a debug build. – Qw3ry May 28 '18 at 19:34
  • If you don't have time-critical devleopment you can work in debug builds, but for things that must fail hard in order to find bugs that are hard to find on code that is otherwise too slow to reproduce issues, it can be a handy tool. – StarShine Sep 06 '22 at 08:02

7 Answers7

33

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
  • 333,147
  • 50
  • 533
  • 760
  • if the assert.h included in the pch file, it might won't work. – Baiyan Huang Mar 07 '09 at 00:33
  • 1
    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(). – Anton Daneyko Dec 13 '09 at 19:37
  • Then it seems that something must be redefining NDEBUG and including `assert.h` again (possibly some other header that's being included). – Michael Burr Dec 13 '09 at 23:15
21

Why not just define your own assert:

#define assert(x) MessageBox(...);
dsm
  • 10,263
  • 1
  • 38
  • 72
Baiyan Huang
  • 6,463
  • 8
  • 45
  • 72
  • 4
    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 Sep 28 '09 at 02:13
  • 4
    I like this, but would like to make one six year late suggestion -- use a different name for your assertion that you would like to exist in release and debug builds like `ndbgassert` or similar. That way you can choose between the two. – Russell Greene Aug 08 '15 at 01:07
  • 3
    How is assert a MessageBox?? Shouldn't it check the condition first? – yairchu Nov 15 '17 at 15:28
5

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 (PDF). 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.

Nico
  • 2,645
  • 19
  • 25
Daniel Daranas
  • 22,454
  • 9
  • 63
  • 116
3

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
  • 28,915
  • 15
  • 75
  • 111
2

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
  • 53,022
  • 10
  • 79
  • 131
1

When using Visual Studio you can undefine the NDEBUG precompiler definition to active asserts in the Release build.

For example you can set $(undefesTheNDEBUG) in your Projekt settings for the /U option and then define the environment variable undefesTheNDEBUG to NDEBUG (SET undefesTheNDEBUG=NDEBUG) or pass it along with msbuild (/p:undefesTheNDEBUG=NDEBUG)

Marco Kinski
  • 302
  • 3
  • 7
0

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
  • 10,634
  • 6
  • 46
  • 76
  • 8
    Well, in Visual C++, you can't legally deliver the C++ debug runtimes, so delivering debug binaries to the client can be a problem if you compile with the DLL runtimes (i.e. /MD or /MDd switches). – paercebal Sep 25 '11 at 14:26
  • 2
    Even though this answer is downvoted, I believe it hits on an important point, which is the notion that changing a bunch of variables between what the developer tests primarily [the debug version], and what is released, is not necessarily a good idea. Experienced developers will attest to the fact Release and Debug versions often exhibit different behavior. – Cameron Feb 07 '14 at 22:52