This course is for experienced C programmers who want to program in C++. The examples and exercises require a basic understanding of algorithms and object-oriented software.
4.6 Asserts and Exceptions
Loading...
Do curso por University of California, Santa Cruz
C++ For C Programmers, Part B
73 classificações
Na lição
Monte Carlo Hex Program, Further advanced C++ Topics and Patterns
This module shows how to use Monte Carlo evaluation in complex games such as Hex and Go. This had led top championship level play in both these games. The module discusses C++ assertions and exceptions for error handling and the new C++ 11 feature static asserts. Finally, the last part of the module introduces the idea of “Design Pattern”, a feature of modern OO programming.
Conheça os instrutores
Ira PohlProfessor
Computer Science
All right, we're switching gears and now we're going into,
back into, deep into C++, and we're doing another topic and
the topic is assertions and exceptions.
And this is a critical topic, both assertions and
exceptions are underutilized in both the C and C++ community.
And ideally, if you use them effectively,
you're going to write much better code.
In, Dijkstra's's world, Dijkstra was actually an applied mathematician.
His belief was in the best of all possible worlds,
I could prove my program is correct.
If I could prove my program is correct,
then it's never going to get into an error full state.
If it's not going to get into an error full state I don't have to test for
errors while the program is running.
So, I'm going to, that's Dijkstra,
Dijkstra says I'm going to attempt to prove my program is correct.
And in proving his program is correct, and
he was part of a group of such computer science professors, logicians,
people like Dijkstra, Court, Tony Hoare was another one in that category.
Another one who had interest in this were people like
John McCarthy, Alan Robinson.
So these people were saying,
let's look at even mechanized ways to get proofs of correctness.
And in building those proofs of correctness, we,
basically building that into the logic of the program.
The programmer would be much better trained and
we could avoid a lot of testing.
Now, in the real world and many of you are professional programmers, what do you do?
You write a piece of code for your company and
then you debug it, you didn't write it correctly and prove it correctly.
You debug it and you debug it by trying it on different data.
And hopefully you start with very simple cases and
you say seems to be working on the simple cases.
Now let me look at more complicated cases and maybe you do some stress testing.
And you look at all the pathways a program can take so you check all its logic.
And indeed there are schemes for doing fairly exhaustive testing and
even keeping the test modules built in through the code so
that they can be used any time the code gets changed.
Okay, so all of that's the real world.
But this idealization led these professors like Dijkstra and
Hoare to assume a worked logic of proof that included assertions.
And we as computer science students, at least in that error, were
frequently asked to test preconditions and postconditions in the code.
That gave us insight into the code being correct.
So the idea was, before we execute some piece of code,
certain parameters have to be within certain values.
Let's say you were going to do a square root.
Well, you know you can't have a square root of a negative number.
Square root is expected to be a real double.
So you would do an assertion test before you did square root of x and
say x is greater than or equal to zero and that would be your precondition.
And then you might have a postcondition.
What would be a postcondition for square root?
Well, you get some answer, let's say y is the answer to square root of x.
So you compute y and, So
we're going to call square root of x, And assign it to y.
So preconditioned, we're going to say, assert, x >,
0 and post condition might be, assert,
y * y = = x.
So here are two assertions that give you confidence that you got the code right.
And if the preconditions and
the postconditions are true we know the code is going to be correct and
their idea was to do proofs but that was pretty hard to do.
Most of us, for a serious program,
could not adequately write out a mathematical proof of its correctness.
So, some of the programming community, including the C programming
community decided to instead of statically writing out a proof,
let the computer check these assertions as part of the actual testing,
running of the code.
Okay, let you think a little bit about this.
So, here's the typical piece of code that leads to errors for loop.
We have your standard for (int i = 0, we have some test condition, i gradient, ++i.
And is this loop going to make sense?
Think about that, see what you think.
The answer is probably not, probably the mistake, and
this would be a very common mistake, is i probably should've been less than n.
Why?
Because you're incrementing think about it.
Let's say n started as, let's say n is three well three wouldn't work.
So if n was something like 3 you would have for
int i equals 0, i greater than n and that would be false.
So you wouldn't even have a loop.
So, you probably want something like, i less than n where n is 3 so
that you get a loop that at least works three times.
And the other problem could be well if n, for example, was -1 then this would
end up being an infinite loop because this would keep having a decrement.
So normally if there's an increment here, this should've been a less than anyway.
If you were doing some kind of precondition assert,
you would probably have tested for that and you could've avoided that.
So asserts will use extensively in C code and was good industrial practice.
They were put into C fairly early on and the C++ community adopted the C asserts.
And they basically are a run time test in which you run a logical test and
if the logical test fails while the program is running,
you get an abort and you get a printed message.
Now, the new thing in C++ is what are we calling Static_asserts?
And this actually, amazingly enough, goes back to Dijkstra and Hoare's idea.
Why not embed in the compiler,
to some extent, a proof checker?
So if I don't have to run the program and I can run some series of tests and
the series of tests tell me that the compile program is going to work.
Then I don't have any overhead asserts, the old style asserts are computational.
So, they are having chronic overhead.
Every time you go through an assert you're doing a computation.
The compile time asserts are done at compile time.
You can think of it as in the old days there were programs like Glint that did
a lot of checking and testing in addition to whatever the programmer did and
gave you warnings about things that look bad.
So these static asserts are in the new standard and
we will also look at how they work.
They're not comprehensive, it's not a fool proof checker.
So things have to be statically checkable, they have to be logical conditions.
It's fairly minimal, but it's still very, very powerful idea.
And we'll see that it's especially powerful when it comes to
the template library.
So first off we have the old stuff.
The old stuff you could get by including C assert, the C library.
And what that provided was essentially a macro and
that macro was void assert with an int expression.
And remember with C, zero is false and everything else is true.
So you did an evaluation of an expression and
you wanted to see if it was zero, the expression is false.
And if it was false, during the running of the program there would be an abort,
a termination with a simple message.
And indeed, the macro could be disabled.
So if you were working in a company and
they didn't want ship code with assertions because there would be too much overhead.
They might have the NDEBUG option, meaning not DEBUG the shippable code,
or compile it without the assertions.
Standard practice, still very valuable.
It's almost more valuable for the programmer to stick in asserts so
that his own logic, he's checking his own logic.
I always tell my students, the asserts seem like none sense.
I know I got that right.
So, I don't, why are you bothering to ask me bring this?
I say you think you got it right, but it's very easy to make a simple mistake
like a less than sign for a greater than sign.
So, the actual additional discipline is just like writing comments,
you should write your comments as you write code.
Because they're reminders to you of what the code is supposed to do.
And they give you better design insight, and they give you more high quality code,
and they make the code more readable.
And the same is just completely true of asserts.
So if you haven't been using asserts in your C or C++ coding,
it's very variable to move over and start using them and even using them generously.
Here's a simple example.
I'm going to print out something which is basically a pointer to an integer type.
I'm going to assert that that's not a null pointer.
And only if it's not a null pointer am I go and do the dereferencing operation.
because otherwise, I would get a run time error for the dereferencing operation.
So there is what you might call a simple precondition test.
And then, if we used it here and actually ran it,
then at run time, this would be okay.
We'd get a print out of five, this would be okay.
We'd also get a print of five.
So here's a reference to the integer, i.
Here's a pointer, and a pointer has been assigned the address of i.
Both are going to print five, but here's q.
Here's another pointer, initially null, and we tried to print from that pointer.
And that's going to do an abort, because it fails the precondition assertion.
Very straightforward, very simple.
Think about using asserts.
What if you have a vector, T and you've done mysort on T?
You're writing your own sort routine rather than
the well tested sort routine from STL.
And your sort is going to be tested on the basic iterator range,
begin and end of some data vector.
And what should the pre and postconditions or
the postcondition assert look like to make sure that the sort worked?
How would you write that?
Okay, I'll leave that to you, I won't give you an answer to that,
but we'll have it as a thread in our forum.
So when we use exception handling especially,
not so much asserts we want to be very careful,
don't forget this is a mechanism for handling errors.
Writing really high quality professional code is avoiding making errors.
So we don't want to induce you into gee it's okay to make errors
as long as the errors get caught.
The asserts are really largely intended for
a pre-released version.
Now, Ordinary code is
going to released with exception handling.
Why? Well, there are situations in which
it isn't so much error.
It's that you've written a perfectly appropriate piece of code or
algorithm, but it's running in a system
that doesn't have the resources to manage that code.
Very simple example might be.
A machine that has Heap assignment that lets you assign,
100,000 integers and if you try to assign off the eap,
200,000 integers, you would run out of memory.
And you've written code, it's perfectly well tested,
it's running fine on your big system and somebody intends to run
it on some thing in which the resources are not quite as generous.
You want the code to say, wait a minute, not enough available memory.
And indeed, Heap allocation has its own exception.
Which lets you monitor that frequently a call
to new if it returns without having available memory,
will throw that exception or will return in address of zero.
So exceptions should be able to deal with resource constraints.
Exceptions should be able to deal with IO difficulties.
For example, you're asking the user to input
a hex position when you're playing your hex program.
And what if they input a hex position in which a stone is already
sitting on that position, well that's an illegal move.
You can't put a second stone on top of a first stone.
So that position not only has to fit, the hex board.
So they have to enter it properly, the hex coordinates.
And they have to enter it properly a stone that's going to be on empty
hex an empty square, an empty hexagonal sort of.
Hard to say hexagonal square, might want to say it.
However, there are big arguments in the programming community, and
one of the arguments goes that exceptions are another way to write gotos.
Exceptions are alternate flow of control.
And if you remember what we called spaghetti code when we were talking in
the really old days of ALGOL,
Pascal, C, fortrend, you just didn't
want to have gotos and test conditions that flipped your code all over the map.
That was unstructured code, very hard to follow,
very hard to pass, very hard not be buggy.
And so, indeed, many organizations would ban gotos.
Gotos where you should write goto list programming, and indeed,
lots of programming languages went to the point of eliminating the goto.
So exceptions are a sneaky way to write in a goto because you can do a throw and
change or alter your ordinary flow of control.
So the argument goes, don't encourage programmers to
think that exception laid in code is somehow high quality.
Though, I'm actually a believer in that.
I would rather you minimize your use of exception and
keep it to very, very clear uses like IO difficulties.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
