The custom Assertion macros provide additional functionality over the standard library's assert macro. There are essentially two different macros included in the CustomAssert.h file: the regular assert and the persistent_assert. The former acts just like the standard assert in that it is only present when the executable is compiled in debug mode (that is, the _DEBUG pre-processor symbol is defined). persistent_assert, on the other hand, performs the assertion unconditionally. Note that the regular assert macro uses INLINE x86 ASSEMBLY, and thus will not work correctly on non-Intel-compliant machines. (Thus, such platforms as, say SPARC, are excluded.) Also note that the non-persistent assert sends a third-level interrupt signal. Thus, to make good use of it, it is best to run the executable from a debugger (otherwise, the user will just get the information that an unhandled exception has been caused (for Win32) or that the program has fallen into the "Trace/Breakpoint trap" (for Linux)). If the program is run from a debugger, like Visual Studio, or gdb, it will break into the code on the line where the assertion macro was called. (Note that, of course, to make use of this feature under linux, one needs to compile the executable with a -g g++ flag, and it is also best to disable optimizations.) Persistent assert, unlike its non-persistent counterpart breaks the execution selectively. If the program was compiled in debug mode, then the same behavior is invoked - a third-level interrupt signal is raised. Otherwise, the assumption is that there is no use for a debug information, and the execution is simply aborted. Note also that both the persistent and non-persistent asserts do not only break the execution of the program, but also write the relevant log information into the LET_Application log. If the program is compiled in debug mode, additional information is also written to the long, namely: the name of the source file where he error occured, and the line of source-code. That is done in case the program was not run from the debugger, so that the programmer would still know where the problem is. Last, but not least, a DISCLAIMER: The code is provided with NO WARRANTY whatsoever and is not guaranteed to function properly nor be fit for any particular purpose. In other words, if you don't like it, or if it breaks something, don't blame me or any member of my team or anybody related to me in any way whatsoever. PS: Ah, yes, another thing. As far as "make"ing the test under Linux goes... Since the utilities contain a few different things, and each of them has a test file associated with it, there is a custom makefile for the assertion test, cunningly named... Makefile.AssertionTest. Of course, if you just call make from the utilities directory, it will complain that it can't see any suitable makefiles. So, tell it the target explicitly by calling like so: $> make -f MakeFile.AssertionTest