C/C++ Question in throwing a class object as exception in C++

[Vanadium 50]

You read my respond? I COPIED STRAIGHT OUT OF THE CD GIVEN BY THE BOOK.

You've said this before and it was not true then. I don't think it's true now.

It's time to face an unfortunate and unpleasant fact: you are not a very good programmer. The reason you are not a very good programmer is twofold:

1. You have clearly not understood the material in the earlier sections but have gone on to later sections. You have not grasped the concept of pointers (chapter 9), arrays (chapter 7), or variable typing (chapter 2).
2. You ignore our attempts to help you. There are literally thousands of messages trying to help you and you make us repeat the same things many, many times. (see #15, #17, #19 and now #25 )

Thus far, you've blamed your book, me, your compilers, PF, your printer and your washing machine. None of them are at fault here. This is all of your doing.

You have a decision to make. You can try and become a better programmer which means changing your behavior, or you can keep doing what you're doing and remain poor at programming. Up to you.

 

[jbunniii]

No I am not, this is an exercise only, even if it were to declare double, I NEVER enter anything with decimals to test the program. Like 2, 3, -1, -3. The point is if the program say integer, just put integer.

I am very literal, if the book provide me the code, I take it literally and not wasting time question on whether it's int or double. My emphasis is on why the program using the class inside and how to interpreted the declaration.

No offense, but this attitude would get you nowhere in a professional or open-source project. A pull request where the author doesn't care about implicit narrowing of double to int because "I NEVER enter anything with decimals to test the program" is a pull request that's going to be declined by any competent software team.

Type safety (e.g. ensuring that the objects provided to a function are of the type expected by the function) is a hugely important theme in C++. Unfortunately, to maintain compatibility with C, it isn't enforced by the compiler for many legacy "plain old data" types such as double and int. This is a major source of bugs, which is why most compilers will emit a warning in this case. (If yours does not, then find the setting to enable warnings for implicit narrowing. Also, you should enable the setting to "treat warnings as errors" instead of ignoring or disabling warnings!)

 

[Vanadium 50]

implicit narrowing

I agree implicit narrowing is a problem. But here I think that's not the problem.

• If the variable will always hold an integer, it should be an int. Period. It should never be a double anywhere in the code.
• If the variable will sometimes be fractional, it should never be an int. Period.

The problem is not implicit narrowing. The problem is a lack of clear thinking about what this variable is supposed to represent.Other problems flow from this.

 

[jbunniii]

I agree implicit narrowing is a problem. But here I think that's not the problem.

• If the variable will always hold an integer, it should be an int. Period. It should never be a double anywhere in the code.
• If the variable will sometimes be fractional, it should never be an int. Period.

The problem is not implicit narrowing. The problem is a lack of clear thinking about what this variable is supposed to represent.Other problems flow from this.

Absolutely agree that this is the underlying problem. My suggestion about enabling the implicit narrowing warning is that it makes it much easier to recognize errors like this in the first place. If @yungman had enabled this warning along with "treat warnings as errors", he would have been aware of, and perhaps fixed, the problem before posting his code here. (Or, if not clear what the problem is and how to proceed, he could have asked about it here!)

This is even more important if he's using code from a CD and assuming that it's correct.

 

[Mark44]

If @yungman had enabled this warning along with "treat warnings as errors", he would have been aware of, and perhaps fixed, the problem before posting his code here.

Like myself, yungman is using Visual Studio, for which the default warning level is W3, one lower than the highest warning level (which treats warnings as errors). When I first ran the code I got the warning about conversion from double to int. I'm almost certain he got the same warning, assuming he compiled and ran the code.

 

[Vanadium 50]

FWIW, this is Program 16-5 in Gaddis, which uses variable names that are un-yungmanized (e.g. myRectangle instead of myRect) and does not mix ints and doubles. So it is not the case that this is an exact copy. Would have saved some time.

I'm glad VS produces a warning for this. It would have been helpful for us to know that the code threw a warning. Would have saved some time.

But anyway...One thing Ada got right is that even Integers have ranges: you can't assign an Integer of one range to another that does not completely contain the first. One thing they got wrong was building in a default Integer type (and worse, with an implementation-dependent range). If you are going to have super-strong typing, have super-strong typing.

The advantage of this is that run-time errors in C/C++ become compile-time errors in Ada.