Thread: Asserts and their ranges

  1. #1
    Registered User
    Join Date
    Oct 2006
    Posts
    5

    Asserts and their ranges

    Code:
    #include <iostream>
    #include <assert.h>
    using namespace std;
    
    const int N_Primes = 7; // Number of Primes
    
    int primes[N_Primes] = {2, 3, 5, 7, 11, 13, 17};
    
    int main( )
    {
              int index = 10;
              
              assert(index < N_Primes);
              cin.get();
              assert(index >= 0);
              cin.get();
              std::cout << "The tenth prime is "  << primes[index] << '\n';
              cin.get();
              return(0);
              
    }
    This is an example from a book I am going through. Why do you need a constant integer, why cant I just set it to a normal integer and then never change it? Also, what does
    Code:
     assert(index >= 0);
    mean? Index is greater then = 0? Why dont I just put it as being greater then N_Primes, since that is what I want it not to go over. So confusing...

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Why do you need a constant integer, why cant I just set it to a normal integer and then never change it?
    It might be late at night and you might forget. If you use constants the compiler will wake you up.

    And another reason: if N_Primes wasn't constant, using it to declare an array would be non-standard. In C++ you can't declare variable size arrays.

    Index is greater then = 0?
    If you get index from user input or some calculation, you'd want to be sure that it won't be negative.
    By the way, the line reads: greater or equal
    Last edited by anon; 10-07-2006 at 09:40 AM.

  3. #3
    Registered User
    Join Date
    May 2006
    Posts
    903
    Basically, assert will crash your program if the condition met is not true. I never really understood why people used assert over if()s or exception handling which won't crash your program and will let you fix on-the-fly errors (i.e. dumb users).

    Besides, I don't know how your program is calculating the tenth prime...

  4. #4
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,005
    Quote Originally Posted by Desolation
    I never really understood why people used assert over if()s or exception handling which won't crash your program and will let you fix on-the-fly errors (i.e. dumb users).
    Because an assert is a tool for checking your code that can automagically be removed. It shouldn't be used in many situations like an if is used.

    http://www.embedded.com/shared/print...icleID=9900096
    http://www.embedded.com/shared/print...icleID=9900128
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    5
    Oh I understand now!!!! What assert declares is the range, not the condition to crash to! What I mean is, I thought it meant if its greater then or equal to zero, CRASH! But what it really means is, if its NOT greater then or equal to zero CRASH!!!

    Ive been up all night studying. Thank you guys again!

  6. #6
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Quote Originally Posted by Desolation
    Basically, assert will crash your program if the condition met is not true. I never really understood why people used assert over if()s or exception handling which won't crash your program and will let you fix on-the-fly errors (i.e. dumb users).
    It doesn't simply crash the program: it also prints in which file and on which line the error occurred to error output. As I understand it, it is only meant to be used while developing / debugging the program.

    When you are finished with debugging, none of the asserts should ever fail. Then you can dissable the asserts by putting #define NDEBUG before you include assert.h

    Besides, I don't know how your program is calculating the tenth prime...

    The program doesn't calculate anything: it just shows how assert works. It can't display the 10th prime, because it only has 7. Assert failing means you'll need to fix something somewhere, for example by changing index to 6 (instead of 10).

  7. #7
    Registered User
    Join Date
    Oct 2006
    Posts
    5
    Yeah. its just an example from a textbook. You can change it to 0-6 and it'll pick up on of the primes. But, we set it to 10 to examine how asserts work.

    Yes. I have the error, that wasnt confusing me. I was confused HOW it worked.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Basically you use assert() everywhere to make certain things are like you expect them to be. It's meant to catch programming errors, not user errors. Though of course an assert might catch a programmer error that causes a user error not to be caught, i.e. user input is not validated and as a result invalid data reaches a place it is not meant to reach.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    asserts are much more than just that. They are documentative, and allow pre / post-condition checking etc.

    e.g.
    If you have a function that takes an int, and the int should never be zero (because it divides by this number say) then you should assert(myInt != 0);
    If your function accepts a pointer and the function would crash if passed NULL (even though you would never do that) then you should assert(myPtr != NULL);
    When used as the first line(s) of the function these can replace (or rather supersede) coments explaining the proper usage of your funtion.

    If you were to write an if-statement for the test then the reader would assume that it is okay to pass NULL etc. But doing so would probably only hide bugs because you'd never know you were doing anything wrong, unless you stepped through it at the right time.

Popular pages Recent additions subscribe to a feed