This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

// Explicitly cast the int into a short (and allow loss of data).

short answer = (short)Add(numb1, numb2);

Console.WriteLine("{0} + {1} = {2}",

numb1, numb2, answer);

NarrowingAttempt();

Console.ReadLine();

}

static int Add(int x, int y)

{ return x + y; }

static void NarrowingAttempt()

{

byte myByte = 0;

int myInt = 200;

C H A P T E R   3  

■

C O R E   C #   P R O G R A M M I N G   C O N S T R U C T S, PA RT   I

96

8849CH03.qxd  9/24/07  11:07 AM  Page 96

---

// Explicitly cast the int into a byte (no loss of data).

myByte = (byte)myInt;

Console.WriteLine("Value of myByte: {0}", myByte);

}

}

Figure 3-15.

OOPS! We lost some data when adding our numbers!

Trapping Narrowing Data Conversions

As you have just witnessed, an explicit cast allows you to force the compiler to apply a narrowing

conversion, even when doing so may result in a loss of data. In the case of the NarrowingAttempt()

method, this was not a problem, as the value 200 can fit snuggly within the range of a byte. How-

ever, in the case of adding the two shorts within Main(), the end result is completely unacceptable

(30,000 + 30,000 = –5536?). If you are building an application where loss of data is always unaccept-

able, C# provides the checked and unchecked keywords to ensure data loss does not escape

undetected.

To illustrate the use of these keywords, assume you have a new method within Program that

attempts to add two bytes, each of which has been assigned a value that is safely below the maxi-

mum (255). If you were to add the values of these types (casting the returned int to a byte), you

would assume that the result would be the exact sum of each member:

static void ProcessBytes()

{

byte b1 = 100;

byte b2 = 250;

byte sum = (byte)Add(b1, b2);