Why does my program using cstring work while the one from the book doesn't?

[yungman]

First of all, we were arguing about your naivety in assuming that figure 15.2 is wrong. Your comments on the page written are wrong. The order the author gives is correct, and his writing matches the figure.

Second, we already went back and forth about your misunderstanding of the writing and of figure 15.3. Again you were WRONG. You pass the blame for your own inability to understand onto the author. You must just accept you're just flat WRONG and fix your understanding. You've got a lot to learn about humility.

No, You only insult, you have not explain ANYTHING. Read post 39, 47 and 60, tell we how I read it wrong. How the writing match the drawings? Which sentence I interpreted wrong? there's only a few sentences in question IF YOU JUST STOP AND READ IT.

Or else there is no point in talking about this anymore. It just going to get ugly. Until you can point out each sentence how it match the drawing, there's no point in talking and I stand by my conclusion.

For cry out loud, these are very simple stuffs, either one way is right or the other.

 

[Jarvis323]

No, You only insult, you have not explain ANYTHING. Read post 39, 47 and 60, tell we how I read it wrong. How the writing match the drawings? Which sentence I interpreted wrong?

Or else there is no point in talking about this anymore. It just going to get ugly. Until you can point out each sentence how it match the drawing, there's no point in talking and I stand by my conclusion.

For cry out loud, these are very simple stuffs, either one way is right or the other.

Are you kidding me? I rephrased the authors writing in a way to try to help you understand it, and explained what the author's language means, I remade the figure to make it more understandable, I rewrote your program so that it would show you the order of the objects destroyed and the copy of the exception. I've answered all of your questions in detail.

What more can you ask for?

It is pretty nice I even went out of my way to read your incoherent post and tried reading your photocopied image that I needed to zoom in on and squint at.

I would be surprised if you actually even read what I've written, and if you have I don't know how in the world you still don't get it.

You asked if the book was wrong, and it isn't. If you're unable to accept that, then why did you ask us in the first place? You just like wasting our time?

 

[pbuk]

That said your writing is really bad, just like the book. If that's what you try to say, I would just say:

You can buy the ticket and USE it ANY DAY. Instead of going in circle to confuse people.

But that would be wrong: you can't use the ticket any day, you can only use the ticket on Thursday if you have not already used it on Tuesday or Wednesday.

All it has to say is fun3 will bypass everything and go straight to catch block.

And this would also be wrong; if this happened then the return address and calling parameters from fun2 would be left on the stack and the program would crash. The critical point that you need to understand is that the exception bubbles up through the call stack until it is handled by a catch block (or if there is no catch block in the stack dealt with as an uncaught exception).

 

[Vanadium 50]

Before you guys start calling me racist

Nobody called you racist. Insinuating that they did is not very nice.

To get back on track, the example in Gaddis is OK for showing how exceptions work, but it is not a very good guide on when to use them.

The reason exceptions exist is to separate error handling code from normal operation code. There is nothing that exceptions do that cannot be done using other C++ features, but using exceptions let's you do this in a way that the program logic is cleaner.

The Gaddis example checks that the input of a positive number is in fact positive. I would call this "validation", and I would claim that good coding practice is to reject the input if you know it is bad and to let the user try again at that point, rather than throwing an exception.

Using try/throw/catch to do bounds checking at the point of input is like using a sledgehammer to kill an ant. An ant standing on a very expensive watch.