[MUSIC] Now we're going to look at very simple test program using asserts. Okay, let's look at this. We've included the assert headed file. And the program merely says assert(0), and remember 0 of course means false. So this is so simple that it basically says, this assert fails. And rather than print My program runs, we should compile this and see the program failing. So let's do that. And when the assertion fails, you see assert failed, function main, the file was assert test1.c line 16, and there was an abort. So the assert is saying a certain precondition does not hold at that point in the program. And as part of what it gives you besides aborting the program is showing you where that happened, that indeed that happened exactly at the assert. Now, Let's look at a second test program. In this program the difference is we've included the NDEBUG flag, it's sharp defined. And what that does is it turns off the asserts when compiled with the NDEBUG bug flag. So now the same program as we saw before, with the exception of adding NDEBUG, we'll do as follows. And it runs as if the program did not have the assert(0) there. So in some sense, the NDEBUG flag lets us use, Asserts, but then wipes them out after we find that the program is running correctly. We can just insert that and say, stop using assertions. So that's one way to develop code, stick in your assertions, in effect, it's a dynamic proof of correctness. And after you're convinced that all the assertions are no longer needed you can just turn them off for the moment. Of course, if you further develop code based on that source they'll be available. And anytime you don't have the sharp define the assertions will be turned back on. Let's look at one more program using asserts. It'll be a simple math program. In this program what are we asserting? There are two doubles, we're going to run an infinite loop. We ask, For two floating point numbers, scanning them, and reading them into x and y. And then we assert that y is not equal to 0, and why is that? because we don't want to divide by 0 here, otherwise we print x divided by y. So if we run that code, and I think I already have it, Compiled. It says, Read in 2 floats. Let's read in 2 floats, dividing for 4 by 5.6 is .714. We can read in two more floats, 3 and 5. That's .6. We can divide 0 by 4.5. That's going to be 0. We're in that infinite loop. But now let's try dividing 5 by 0, see what happens. There, it's an assertion fail. So it's not recommended for us getting out of such an infinite loop. Normally we would have something we would either read as sentinel, or we would use in the case of most Unix operating systems, Ctrl+C to end the program as well. Now, one last thing, what happens if we compile that without. With an effect and NDEBUG flag. And we can see how to do that with our GNU compiler. We do a -DNDEBUG as part of the compilation. And that's telling us turn off the asserts. And now let's run the same program except that the asserts have been turned off. And now, we can read in, let's say, 3 and 4, sure enough, 2 and 1, sure enough. But now, when we read 7 over 0, instead of getting an assertion era, we get 1 divided x over y is inf and that's the system provided infinity. Now it's sort of interesting, what if you divide 0 by 0? It also doesn't abort. Instead, it just says not a number. So these are two interesting constructs when we get some mathematical operation that can't be interpreted in the normal set of reals. And now because we can't, we're in the infinite loop and its waiting for floats. And we don't have the ability to write in a 0, which we used before to create both. We will just do Ctrl+C, and get out of there. Okay, so that's our asserts, we saw it in code, very useful. Especially if you're going to be a careful coder, it helps, just in your logic, to think about what asserts can do as preconditions and post-conditions in checking your code. [MUSIC]
