|Access||Adobe photoshop||Algoritmi||Autocad||Baze de date||C||C sharp|
|Calculatoare||Corel draw||Dot net||Excel||Fox pro||Frontpage||Hardware|
|Php||Power point||Retele calculatoare||Sql||Tutorials||Webdesign||Windows|
|Asp||Autocad||C||Dot net||Excel||Fox pro||Html||Java|
The word cast is used in the sense of “casting into a mold.” Java will automatically change one type of data into another when appropriate. For instance, if you assign an integral value to a floating-point variable, the compiler will automatically convert the int to a float. Casting allows you to make this type conversion explicit, or to force it when it wouldn’t normally happen.
To perform a cast, put the desired data type (including all modifiers) inside parentheses to the left of any value. Here’s an example:
As you can see, it’s possible to perform a cast on a numeric value as well as on a variable. In both casts shown here, however, the cast is superfluous, since the compiler will automatically promote an int value to a long when necessary. You can still put a cast in to make a point or to make your code more clear. In other situations, a cast is essential just to get the code to compile.
In C and C++, casting can cause some headaches. In Java, casting is safe, with the exception that when you perform a so-called narrowing conversion (that is, when you go from a data type that can hold more information to one that doesn’t hold as much) you run the risk of losing information. Here the compiler forces you to do a cast, in effect saying “this can be a dangerous thing to do – if you want me to do it anyway you must make the cast explicit.” With a widening conversion an explicit cast is not needed because the new type will more than hold the information from the old type so that no information is ever lost.
Java allows you to cast any primitive type to any other primitive type, except for boolean, which doesn’t allow any casting at all. Class types do not allow casting. To convert one to the other there must be special methods. (String is a special case, and you’ll find out later in the book that objects can be cast within a family of types; an Oak can be cast to a Tree and vice-versa, but not to a foreign type such as a Rock.)
Ordinarily when you insert a literal value into a program the compiler knows exactly what type to make it. Sometimes, however, the type is ambiguous. When this happens you must guide the compiler by adding some extra information in the form of characters associated with the literal value. The following code shows these characters:
Hexadecimal (base 16), which works with all the integral data types, is denoted by a leading 0x or 0X followed by 0–9 and a–f either in upper or lower case. If you try to initialize a variable with a value bigger than it can hold (regardless of the numerical form of the value), the compiler will give you an error message. Notice in the above code the maximum possible hexadecimal values for char, byte, and short. If you exceed these, the compiler will automatically make the value an int and tell you that you need a narrowing cast for the assignment. You’ll know you’ve stepped over the line.
Octal (base 8) is denoted by a leading zero in the number and digits from 0-7. There is no literal representation for binary numbers in C, C++ or Java.
A trailing character after a literal value establishes its type. Upper or lowercase L means long, upper or lowercase F means float and upper or lowercase D means double.
Exponents use a notation that I’ve always found rather dismaying: 1.39 e-47f. In science and engineering, ‘e’ refers to the base of natural logarithms, approximately 2.718. (A more precise double value is available in Java as Math.E.) This is used in exponentiation expressions such as 1.39 x e-47, which means 1.39 x 2.718-47. However, when FORTRAN was invented they decided that e would naturally mean “ten to the power,” which is an odd decision because FORTRAN was designed for science and engineering and one would think its designers would be sensitive about introducing such an ambiguity. At any rate, this custom was followed in C, C++ and now Java. So if you’re used to thinking in terms of e as the base of natural logarithms, you must do a mental translation when you see an expression such as 1.39 e-47f in Java; it means 1.39 x 10-47.
Note that you don’t need to use the trailing character when the compiler can figure out the appropriate type. With
there’s no ambiguity, so an L after the 200 would be superfluous. However, with
the compiler normally takes exponential numbers as doubles, so without the trailing f it will give you an error telling you that you must use a cast to convert double to float.
You’ll discover that if you perform any mathematical or bitwise operations on primitive data types that are smaller than an int (that is, char, byte, or short), those values will be promoted to int before performing the operations, and the resulting value will be of type int. So if you want to assign back into the smaller type, you must use a cast. (And, since you’re assigning back into a smaller type, you might be losing information.) In general, the largest data type in an expression is the one that determines the size of the result of that expression; if you multiply a float and a double, the result will be double; if you add an int and a long, the result will be long.
John Kirkham writes
“I started computing in 1962 using FORTRAN II on an IBM 1620. At that time
and throughout the 1960s and into the 1970s
FORTRAN was an all uppercase language. This probably started because many of
the early input devices were old teletype units
which used 5 bit Baudot code
which had no lowercase capability. The ‘E’ in the exponential notation was also
always upper case and was never confused with the natural logarithm base ‘e’
which is always lower case. The ‘E’ simply stood for exponential
which was for the base of the number system used – usually 10. At the time
octal was also widely used by programmers. Although I never saw it used, if I
had seen an octal number in exponential notation I would have considered it to
be base 8. The first time I remember seeing an exponential using a lower case
‘e’ was in the late 1970 s and I also found it confusing. The
problem arose as lowercase crept into FORTRAN, not at it s
beginning. We actually had functions to use if you really wanted to use the natural
logarithm base, but they were all uppercase.”
Politica de confidentialitate|
Adauga cod HTML in site