How overload a define macro?

This is a discussion on How overload a define macro? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by medievalelks I don't do debug builds unless I'm, well, debugging. All unit testing and QA is done ...

  1. #16
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by medievalelks View Post
    I don't do debug builds unless I'm, well, debugging. All unit testing and QA is done on the release build
    Of course. The point is, if the asserts are disabled for release, then your QA testing (in other words, the real testing) will never hit them, which makes them pointless.

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by phantomotap View Post
    Same. Difference. (I was only asking if you kept the assert; not for the particulars of the implementation. I don't care if it 'abort's of not.)

    Still... I think I'm in love. First person I ever met that has the good sense to keep an assert in release builds.

    Soma
    Not sure I want you to be in love with me (my wife certainly would get a bit jealous, either way) or some of my current and former collegues [I think some of those are single], but I can assure you that you are not alone.

    Where I work, we have a choice "debug" and "always" asserts - obviously, debug asserts are for debug builds (checking for programmer errors, or extra checking that don't actually make things go terribly wrong [just stupid/wrong to do]), whilst always asserts are there all the time, for checking against things that will definitely go wrong, but not necessarily at a point where it can be easily identified.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #18
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Requirements of high criticality code (eg developed to SIL 4 - safety critical) would not work well with asserts(). For those types of development it is generally necessary to define requirements (preconditions, postconditions, etc) of code, and then ensure through analysis and design that the code IS NOT invoked in any way that does not meet the requirements. Using a run-time mechanism to detect violated requirements is insufficient to satisfy such demands.

    Consider software that monitors human vital signs and controls a respirator: the set of conditions when that software can terminate safely are very small (eg when medical staff consider it appropriate to take the patient off the respirator).

  4. #19
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by grumpy View Post
    Requirements of high criticality code (eg developed to SIL 4 - safety critical) would not work well with asserts(). For those types of development it is generally necessary to define requirements (preconditions, postconditions, etc) of code, and then ensure through analysis and design that the code IS NOT invoked in any way that does not meet the requirements. Using a run-time mechanism to detect violated requirements is insufficient to satisfy such demands.

    Consider software that monitors human vital signs and controls a respirator: the set of conditions when that software can terminate safely are very small (eg when medical staff consider it appropriate to take the patient off the respirator).
    Sure, and asserts that fire regularly even if the code is not safety-critical is still very bad. The point of having an assert is to make the error condition more recognizable. I presume that safety-critical devices also have to ensure that memory violations are not halting the system, for example, and an assert(p != NULL) would not really do here - you need full checking that the pointer is valid before attempting to use it [or make sure pointers are never invalid, which of course is a better approach].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #20
    Registered User
    Join Date
    Jun 2005
    Posts
    6,245
    Quote Originally Posted by matsp View Post
    you need full checking that the pointer is valid before attempting to use it [or make sure pointers are never invalid, which of course is a better approach].
    In high criticality code, the more usual approach is to ensure pointers are never invalid in the first place. In practice, that means a few constraints (eg dynamic memory allocation is rarely used in a high critical application, except in a clearly defined startup or initialisation phase, reinitialisation virtually never occurs, etc) as that makes it easier to analyse the code and gather evidence that unwanted behaviours do not occur (or are acceptably unlikely to occur).

    Clearly that requires a lot more analysis (both of functions, and how the system as a whole uses them). But a side-effect is that assertions are generally unneeded: the system design prevents low level assertions from failing anyway.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Help me with function call
    By NeMewSys in forum C++ Programming
    Replies: 16
    Last Post: 05-22-2008, 01:53 PM
  2. C Programming 2d Array Question
    By jeev2005 in forum C Programming
    Replies: 3
    Last Post: 04-26-2006, 03:18 PM
  3. whats wrong here
    By sreetvert83 in forum C++ Programming
    Replies: 15
    Last Post: 09-21-2005, 10:05 AM
  4. Error check problem again
    By rtransfi in forum C Programming
    Replies: 6
    Last Post: 02-27-2003, 03:55 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21