using System;

// The Point class is derived from System.Object.
class Point
{
public int x, y;

public Point(int x, int y)
{
this.x = x;
this.y = y;
}

public override bool Equals(object obj)
{
// If this and obj do not refer to the same type, then they are not equal.
if (obj.GetType() != this.GetType()) return false;

// Return true if x and y fields match.
Point other = (Point) obj;
return (this.x == other.x) && (this.y == other.y);
}

// Return the XOR of the x and y fields.
public override int GetHashCode()
{
return x ^ y;
}

// Return the point's value as a string.
public override String ToString()
{
return String.Format("({0}, {1})", x, y);
}

// Return a copy of this point object by making a simple field copy.
public Point Copy()
{
return (Point) this.MemberwiseClone();
}
}

public sealed class App {
static void Main()
{
// Construct a Point object.
Point p1 = new Point(1,2);

// Make another Point object that is a copy of the first.
Point p2 = p1.Copy();

// Make another variable that references the first Point object.
Point p3 = p1;

// The line below displays false because p1 and p2 refer to two different objects.
Console.WriteLine(Object.ReferenceEquals(p1, p2));

// The line below displays true because p1 and p2 refer to two different objects that have the same value.
Console.WriteLine(Object.Equals(p1, p2));

// The line below displays true because p1 and p3 refer to one object.
Console.WriteLine(Object.ReferenceEquals(p1, p3));

// The line below displays: p1's value is: (1, 2)
Console.WriteLine("p1's value is: {0}", p1.ToString());
}
}

// This code example produces the following output:
//
// False
// True
// True
// p1's value is: (1, 2)
//

This is a gotcha regarding all number types in .NET but will most likely surface in your code in an Int32 just because it's used so often.

What do you think will happen when you try to put a number that is too big into an Int32 (as an example... the same rule applies for any number type ie Int16, Int64, UInt32, etc)? I expect something like an Overflow exception... well, if you write in VB that is what will happen... in C# it wont!

The short reason why this is is that the VB compiler will emit the Intermediate Language OpCode Add.Ovf (if you say add to a number) which is the code that makes the runtime throw an exception if the number is too large for it's type (an Int32 limit is +- 2,147,483,647) so if you had 2,147,483,647 in an Int32 and add one to it, code compiled by the VB compiler will throw an System.OverflowException. If the code is compiled in C#, it won't do anything! the number will just be wrong!

Before you start ragging on C# all you VB developers.... think about how often you care about overflows.... I can safely say that I almost NEVER do. All my for loops are like in the range of hundreds usually. Well, if I wrote the for loop in VB, every time through where it adds one its going to check for overflow. I KNOW it will never overflow, but the runtime is going to check everytime anyway. So the philosophy of C# which comes from the C family. C++ acts the same way in regards to overflows. Note that checking for overflow takes more clock cycles so C# has opted for performance by default while VB has opted for be-safe by default. This makes sense considering the philosophy and intent behind both languages, but makes dealing with overflows really problematic.

C# CAN check for overflows if you want it to. you can make it act like VB (ALWAYS check for overflows) with the /Checked+ compiler switch. OR you can check for individual var overflows with the 'checked' operator thusly:

try
{
    checked
    {
        System.Int32 checkedTooBig = int32Max * int32Max;
    }
}
catch (System.OverflowException)
{
    DoSomething();
}

This has the really odd byproduct that if you consume a library written in VB your numbers will throw overflow exceptions when you call into it. If you consume a library written in C# you don't really know if your numbers will throw overflow exceptions or not since it depends on how it was compiled (i.e. did the compile with the /checked+ switch) or if they used the 'checked' operator on an individual operation.

This is a great example of the problems related to language interop in my opinion. C# developers can write C# code without checked math operations that will NOT throw exceptions on overflow. This code is CLSCompliant. VB developers can then use this library, but they won't get what they expect! The same is true the other direction. C# developers might expect that overflows NOT throw exceptions, but if they consume an assembly written in VB overflow exeptions would occur. To make matters worse, without looking directly at the intermediate language, you have NO idea when you are consuming an assembly if the overflow throws an exception or not.

Moreover, you can't be paranoid and just check all your external assembly calls like this:

try
{
    checked // this won't check the method call for overflow even though it looks like it would
    {
        ExternalLibraryMethodThatDoesMath(myInt32);
    }
}
catch(System.OverflowException)
{
}

because the checked operator's only function in life is to tell the compiler to emit the correct OpCode to check for overflows or not. It's can't apply an overflow check to a 'Call' OpCode... So you can't check to make sure the ExternalLibraryMethodThatDoesMath() will throw an exception on overflow...it's entirely dependent on how that assembly was compiled.



I was curious what the behavior would be in SQL Server 2005 so I tried it in Management Studio. I opened a table and modifed a field of type "INT" to 2,147,483,648 (2,147,483,647 + 1) and thankfully it produced an error "Invlaid value for cell". So I guess if you're a C# user, you still have a safety net to prevent you from storing bad numeric data.