Prev: Urgent! C# Developer wanted in the Chicagoland area!
Next: TCP connections from a listening port
From: trubar a on 15 Jun 2010 15:47
hi

1) Is UNCHECKED operator in effect only when expression inside
UNCHECKED context uses an explicit cast ( such as byte
b1=unchecked((byte)2000); ) and when conversion to particular type can
happen implicitly? I’m assuming this since the following expression
throws a compile time error:

byte b1=unchecked(2000); //compile time error

2)

a) Do CHECKED and UNCHECKED operators work only when resulting value
of an expression or conversion is of an integer type? I’m assuming
this since in the first example ( where double type is being converted
to integer type ) CHECKED operator works as expected:

double m = double.MaxValue;
b = checked( (byte) m ); // reports an exception

, while in second example ( where double type is being converted to a
float type ) CHECKED operator doesn’t seem to be working. since it
doesn't throw an exception:

double m = double.MaxValue;
float f = checked( (float) m ); // no exception thrown

b) Why don’t the two operators also work with expressions where type
of a resulting value is of floating-point type?

2) Next quote is from Microsoft’s site:

"The unchecked keyword is used to control the overflow-checking
context for integral-type arithmetic operations and conversions"

I’m not sure I understand what exactly have expressions and
conversions such as unchecked( (byte) (100+200) ); in common with
integrals?

Thank you
From: Peter Duniho on 15 Jun 2010 23:19
trubar a wrote:
> hi
>
> 1) Is UNCHECKED operator in effect only when expression inside
> UNCHECKED context uses an explicit cast ( such as byte
> b1=unchecked((byte)2000); ) and when conversion to particular type can
> happen implicitly? I�m assuming this since the following expression
> throws a compile time error:
>
> byte b1=unchecked(2000); //compile time error

As with every other construct in C# that uses parentheses, the thing
outside the parentheses applies only to those things inside the parentheses.

So, in your example above, the "unchecked" happily allows the constant
2000, but then you still have an "int" constant as the result of the
"unchecked" expression, which is still not valid to assign to a "byte".

Try:

byte b1 = unchecked((byte)2000);

> 2)
>
> a) Do CHECKED and UNCHECKED operators work only when resulting value
> of an expression or conversion is of an integer type? I�m assuming
> this since in the first example ( where double type is being converted
> to integer type ) CHECKED operator works as expected:
>
> double m = double.MaxValue;
> b = checked( (byte) m ); // reports an exception
>
> , while in second example ( where double type is being converted to a
> float type ) CHECKED operator doesn�t seem to be working. since it
> doesn't throw an exception:
>
> double m = double.MaxValue;
> float f = checked( (float) m ); // no exception thrown

From the documentation: "The checked keyword is used to explicitly
enable overflow checking for integral-type arithmetic operations and
conversions."
http://msdn.microsoft.com/en-us/library/74b4xzyw.aspx

Note the "integral-type arithmetic operations".

> b) Why don�t the two operators also work with expressions where type
> of a resulting value is of floating-point type?

See above.

> 2) Next quote is from Microsoft�s site:
>
> "The unchecked keyword is used to control the overflow-checking
> context for integral-type arithmetic operations and conversions"
>
> I�m not sure I understand what exactly have expressions and
> conversions such as unchecked( (byte) (100+200) ); in common with
> integrals?

The word "integral" here refers to integer types, not calculus.

Pete
From: Göran Andersson on 16 Jun 2010 05:56
On 2010-06-15 21:47, trubar a wrote:
> hi
>
> 1) Is UNCHECKED operator in effect only when expression inside
> UNCHECKED context uses an explicit cast ( such as byte
> b1=unchecked((byte)2000); ) and when conversion to particular type can
> happen implicitly? I�m assuming this since the following expression
> throws a compile time error:
>
> byte b1=unchecked(2000); //compile time error
>

It's the assignment that causes the overflow, not the literal value
itself, and the assignment is outside the unchecked context.

> 2)
>
> a) Do CHECKED and UNCHECKED operators work only when resulting value
> of an expression or conversion is of an integer type? I�m assuming
> this since in the first example ( where double type is being converted
> to integer type ) CHECKED operator works as expected:
>
> double m = double.MaxValue;
> b = checked( (byte) m ); // reports an exception
>
> , while in second example ( where double type is being converted to a
> float type ) CHECKED operator doesn�t seem to be working. since it
> doesn't throw an exception:
>
> double m = double.MaxValue;
> float f = checked( (float) m ); // no exception thrown
>

Casting a double to float doesn't cause an overflow. If the value is
outside the range that the float can handle, the result is infinity or
negative infinity. This is just a loss of precision, not an overflow.

> b) Why don�t the two operators also work with expressions where type
> of a resulting value is of floating-point type?

As floating point values have a representation for infinite values, they
simply can't overflow.

> 2) Next quote is from Microsoft�s site:
>
> "The unchecked keyword is used to control the overflow-checking
> context for integral-type arithmetic operations and conversions"
>
> I�m not sure I understand what exactly have expressions and
> conversions such as unchecked( (byte) (100+200) ); in common with
> integrals?
>

The term integral in this case comes from abstract algebra, not
calculus, and means integer numbers.

--
G�ran Andersson
_____
http://www.guffa.com
From: trubar a on 17 Jun 2010 18:27
On Jun 15, 8:19 pm, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote:
> trubar a wrote:
> > hi
>
> > 1) Is UNCHECKED operator in effect only when expression inside
> > UNCHECKED context uses an explicit cast ( such as byte
> > b1=unchecked((byte)2000); ) and when conversion to particular type can
> > happen implicitly? I’m assuming this since the following expression
> > throws a compile time error:
>
> > byte b1=unchecked(2000); //compile time error
>
> As with every other construct in C# that uses parentheses, the thing
> outside the parentheses applies only to those things inside the parentheses.
>
> So, in your example above, the "unchecked" happily allows the constant
> 2000, but then you still have an "int" constant as the result of the
> "unchecked" expression, which is still not valid to assign to a "byte".
>
> Try:
>
>    byte b1 = unchecked((byte)2000);
>

a) Couldn’t same be argued about checked operator? Namely, that
checked also allows the constant 2000 and the result of an error is
actually assignment of int value to variable of type byte.?

b) The following gives me an overflow error:

long l = checked (int.MaxValue + 16);

Since there was no casting, what exactly did overflow? I realize the
expression inside checked context was of int type and that result
exceeded the max value that int type can hold, but instead of
overflowing why didn’t expression automatically get converted to
long type?


c) “If neither checked nor unchecked is used, a constant expression
uses the default overflow checking at compile time, which is checked.”

If I understand the above quote correctly, then at compile time it is
as if our whole program code is inside some “invisible” checked
context, which monitors explicit/ implicit conversions of constants
( which are part of constant expression ) and it is thus this checked
context that actually throws an error when the statements like byte b1
= 2000; are encountered:
From: Peter Duniho on 18 Jun 2010 01:41
trubar a wrote:
> [...]
>> So, in your example above, the "unchecked" happily allows the constant
>> 2000, but then you still have an "int" constant as the result of the
>> "unchecked" expression, which is still not valid to assign to a "byte".
>>
>> Try:
>>
>> byte b1 = unchecked((byte)2000);
>>
>
> a) Couldn�t same be argued about checked operator? Namely, that
> checked also allows the constant 2000 and the result of an error is
> actually assignment of int value to variable of type byte.?

I don't know what you are saying. But, "checked" and "unchecked" both
work the same way: they apply to what's _in_ the parentheses. The value
of the expression _after_ the "checked" or "unchecked" is applied has to
be legal. This is usually accomplished by casting the value inside the
parentheses to the destination type, so that the expression type is
exactly the destination type and no error occurs.

> b) The following gives me an overflow error:
>
> long l = checked (int.MaxValue + 16);
>
> Since there was no casting, what exactly did overflow?

It's because there's no casting that the overflow occurs. int.MaxValue
is a 32-bit int, so the type of the expression "int.MaxValue + 16" is a
32-bit int, and the result of that expression doesn't fit in a 32-bit
int. Thus the overflow.

> I realize the
> expression inside checked context was of int type and that result
> exceeded the max value that int type can hold, but instead of
> overflowing why didn�t expression automatically get converted to
> long type?

Because that's not how it works. The conversion to "long" happens only
_after_ the expression has been evaluated. The destination type is not
considered during the actual evaluation of the expression.

> c) �If neither checked nor unchecked is used, a constant expression
> uses the default overflow checking at compile time, which is checked.�
>
> If I understand the above quote correctly, then at compile time it is
> as if our whole program code is inside some �invisible� checked
> context, which monitors explicit/ implicit conversions of constants
> ( which are part of constant expression ) and it is thus this checked
> context that actually throws an error when the statements like byte b1
> = 2000; are encountered:

I don't know why you use the word "invisible". But yes, the default is
for expressions that are evaluated at compile time to be checked, and
for expressions that are evaluated at run-time to be unchecked. The
disparity may seem odd, but it makes sense from the point of view of
balancing code correctness and performance.

Pete
 |  Next  |  Last
Pages: 1 2
Prev: Urgent! C# Developer wanted in the Chicagoland area!
Next: TCP connections from a listening port