http://embeddedgurus.com/state-space/2009/11/a-nail-for-a-fuse/ A Blog by Miro Samek Tue, 08 May 2012 09:20:07 +0000 hourly 1 http://wordpress.org/?v=3.3.1 http://embeddedgurus.com/state-space/2009/11/a-nail-for-a-fuse/comment-page-1/#comment-35 Miro Samek Sat, 30 Jan 2010 01:58:19 +0000 http://embeddedgurus.com/state-space/2009/11/27/a-nail-for-a-fuse/#comment-35 In embedded systems you typically need to define your own assertion macro, as the standard <assert.h> is not applicable (no stderr to write to and no OS to exit to either). As you define your own assetion macro, you typically end up calling a function to handle the assertion violation (see for example my DDJ article <a href="http://www.ddj.com/cpp/184401686" rel="nofollow">"An Exception or a Bug?"</a>). This callback function is perhaps a better place to differentiate the behavior in the production code vs. debug version:void onAssert__(char const *file, int line) {#ifdef NDEBUG /* release version? */ . . .#else /* debug version */ . . . #endif} In embedded systems you typically need to define your own assertion macro, as the standard <assert.h> is not applicable (no stderr to write to and no OS to exit to either). As you define your own assetion macro, you typically end up calling a function to handle the assertion violation (see for example my DDJ article "An Exception or a Bug?"). This callback function is perhaps a better place to differentiate the behavior in the production code vs. debug version:void onAssert__(char const *file, int line) {#ifdef NDEBUG /* release version? */ . . .#else /* debug version */ . . . #endif}

]]> http://embeddedgurus.com/state-space/2009/11/a-nail-for-a-fuse/comment-page-1/#comment-33 fileoffset Sat, 30 Jan 2010 01:36:34 +0000 http://embeddedgurus.com/state-space/2009/11/27/a-nail-for-a-fuse/#comment-33 One way to leave assertions in but not produce unexpected results in production, is to define a macro or set of macro's that you would use instead of the classic assert(). You can then modify the behavior of the assert macro's so they function differently for production and debug code. For example:#ifdef DEBUG#define ASSERT(a) assert(a)#elsif RELEASE#define ASSERT(a) lcd.displayError(a)#endif One way to leave assertions in but not produce unexpected results in production, is to define a macro or set of macro's that you would use instead of the classic assert(). You can then modify the behavior of the assert macro's so they function differently for production and debug code. For example:#ifdef DEBUG#define ASSERT(a) assert(a)#elsif RELEASE#define ASSERT(a) lcd.displayError(a)#endif

]]>