1. You should use int and double for your integral and floating-point types, rather than trying to use byte, short, long, or float. There are two reasons for this:

We are not working with code that needs to restrict the amount of space used.

In C++, integer literals are of type int, not byte, short, long, and likewise, floating-point literals are of type double, not float. So, if you wanted to do something such as:

byte value;
value = 2;

the program would not compile since you cannot write a value of type int into a variable of type byte. (The way to actually assign values into variables of type byte is not something we'll be discussing in this course, but it's not too complex once you know how to do it.)

2. You can always assume we will deal only in legal values for a type. This means, for example, that no calculations you ever do with integers will exceed the legal range of an integer. Same with the other types -- you can assume that anywhere in your program you are dealing with a char, or a double, that it's a legal char or double that will be understood by the virtual machine, rather than being too big or too small, or whatever.

Of course, the assignment itself might have additional rules about what is allowed. For example, we might promise in the assignment handout that all integer input values we test with will be positive. Or, on the other hand, we might state that your program should expect to possibly see negative integers as input, and that your program should treat them as errors and deal with them in some way. Or maybe any integer at all will be legal input for your program. That sort of thing depends on the particular details of the assignment. All we are saying in the previous paragraph is that you can at least be certain we won't exceed a type's range. Any other restrictions on what values you might have to deal with, will be mentioned in the assignment handout, and if we don't mention such restrictions, you should assume there are no additional restrictions.

Along with that, we will never send in the wrong type of input to one of your input requests. For example, if we've told you to input two integers and a character, in that order, then our input would be two integers and a character, in that order. We won't send in a floating-point number when your program should expect an integer, nor would we send in a character when your program should expect a double, nor would we have any other sort of type mismatch. The mismatch would crash the program in most such situations, and we do not expect you to be able to work around that. HOWEVER -- this does mean you need to ask for input in the order we indicate in an assignment. If we say to input two integers and a floating-point value, in that order, and your code is written to input the floating-point value before the integers rather than after the integers, then you'll have problems that are entirely your own fault.

3. Be aware that it is indeed acceptable -- from a "matching output" perspective -- to have a floating-point number that differs from ours in the last few significant digits of the number. For example, if the number in our output is 34.6779911, you can have 34.6779908 or 34.6779915 instead, although something like 34.6700012 would be wrong, since your number should match for at least the first bunch of places to the right of the decimal. Keep in mind that something like 2.0 would be equivalent to 2.000000000, so if our number is 2.0, you can print 2.000000005 or 1.999999998 and both of those are okay. These differences happen because of computer arithmetic issues; there are ways of rounding to a smaller number of decimal places, but they require things we don't want to get into yet, so for now we'll just have you print out the full precision of a double variable, and accept that your value might be different from ours in a distant decimal place.