A few days ago I had to solve some very ugly bug that was caused by exactly the same approach I mentioned.

The code contained some calculation with a very large numbers and some how the results weren’t close to what we expected.

Let’s see some code

            // Example #2
            var firstValue = 3;
            var secondValue = 0;
            var result = firstValue / secondValue;

Simple, isn’t it. Running the above code will throw DivideByZeroException exception as we all expected.

Now look at the following code. Will it behave the same way ?

            // Example #2
            var firstValue = 3.5;
            var secondValue = 0;
            var result = firstValue / secondValue;

As you probably suspected – it won’t. It will run and complete without throwing any exception at all.
So, what happened here ? Are we talking about some serious bug Microsoft isn’t aware of ?

Well, first of all it is not a bug. The difference between the two examples is the type we are trying to divide by zero. In the first example firstValue is an Integer and in the second example is Double.

Does that mean we can divide floating point numbers by zero ? Yes we can.

Now you are probably wondering what will be the the value of result. Well, the answer is – Infinity. Yes, there is a value called Infinity and to be more specific, in our case the result is a Positive Infinity. The interesting part is because Infinity is a value you can make calculations with it and it won’t throw any exception. Let’s see some examples :

            var i = 3.5 / 0;                // Infinity
            var t1 = i++;                   // Infinity
            var t2 =  i--;                  // Infinity
            var t3 = i/i;                   // NaN
            var t4 = i * i;                 // Infinity
            var t5 = i>0;                   // true
            var t6 = i > double.MaxValue;   // true
            var t7 = double.MaxValue - i;   // -Infinity [ Negative Infinity ]
            var t8 = i-i;                   // NaN

So, now we know that calculations using Infinity are possible but in most cases the result won’t be something you can use for further calculation. By the way, if you will try to insert Infinity into Microsoft SQL field (at least in 2005) it will throw an exception saying “The supplied value is not a valid instance of data type float”.

And now i would like to return to the bug i was talking about at the beginning of this post.
What do you think will be the result of the following code.

            var i = 3.5 / 0;
            var result = (long)i;

The result is very numeric, not NaN and not Infinite but -9223372036854775808.
Now imagine situation when you must calculate some numbers that represent money, I mean loans, balance, etc. I’m sure you can easily understand how far can it go and which unpleasant result we can get.

C# provide us some usefull functions and constants we can and must use to avoid the above mistakes.

            //  Returns a value indicating whether the specified number
            //  evaluates to negative or positive infinity
            double.IsInfinity(double d) 

            //  Returns a value indicating whether the specified number
            // evaluates to negative infinity.
            double.IsNegativeInfinity (double d)

            //  Returns a value indicating whether the specified number
            //  evaluates to positive infinity.
            double.IsPositiveInfinity (double d)

            //  Represents negative infinity. This field is constant.
            double.NegativeInfinity 

            //  Represents positive infinity. This field is constant.
            double.PositiveInfinity

            //  Represents a value that is not a number (NaN).
            //  This field is constant.
            double.NaN

Floating point is necessary in so many cases – use it wisely and carefully.

        if (a-b) alert("it's true!");

And another one

What will be printed as result of running this script:

	for (var n=10; n; n-- )
	{
		document.write (n + ",");
	}

The answer for both questions relies on the same principle of what JavaScript engine will evaluate as true and what as false.

Will the following code compile and if yes what will be the result of it ?

static void Main(string[] args)
{
    int[] array = new[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

    Func<int, int> func = i => {
                          Console.Write(array[i]);
                          return i;
                     };

    var result = array.Where(e => e <= func(2)).ToArray ();
}

static void Main(string[] args)
{
    for (byte b = byte.MinValue; b <= byte.MaxValue; b++)
        Console.Write(b);
}

// A little tip
// byte.MinValue = 0
// byte.MaxValue = 255

How many times the above statement will be executed ?

Forget for a second about .NET.
If someone asks you how much is 1.000025 – 0.000025 your answer will probably be “1″ and correct. An easy question, right ?

Now, let’s go back to .NET and check if our calculations are correct.

        static void Main(string[] args)
        {
            double d1 = 1.000025;
            double d2 = 0.000025;
            Console.WriteLine((d1 - d2) == 1);
        }

If you think the result will be “true”… well, it’s not.

Let’s see another example :

        static void Main(string[] args)
        {
            double d1 = 1.000025;
            double d2 = 0.000025;

            // Will result 1
            Console.WriteLine(d1 - d2);

            // Will result 0.99999999999999989
            Console.WriteLine((d1 - d2).ToString ("R"));
        }

For those who might not know, the meaning of ToString(“R”) is Round-trip.

This format is supported only for the Single and Double types. The round-trip specifier guarantees that a numeric value converted to a string will be parsed back into the same numeric value. When a numeric value is formatted using this specifier, it is first tested using the general format, with 15 spaces of precision for a Double and 7 spaces of precision for a Single. If the value is successfully parsed back to the same numeric value, it is formatted using the general format specifier. However, if the value is not successfully parsed back to the same numeric value, then the value is formatted using 17 digits of precision for a Double and 9 digits of precision for a Single.

So, what happened here ? Is it a bug ?
The answer is – NO, IT’S NOT A BUG ( and it’s not happening only on my computer ).

The thing is, that the above is about how .NET rounding a floating point number.
I won’t explain here the math ( there is already a great article explaining it ), and i won’t say don’t use floating point types.

You just need to know that when you are using it – be carefull, especialy in equations and formatting, otherwise your calculations will be wrong and your result not accurate.

What will be the output of the next code ?

static void Main(string[] args)
{
    int i = 100;
    for (int n = 0; n < 100; n++)
    {
         i = i++;
    }
    Console.WriteLine(i);
}

SELECT CustomerID AS 'data()'
FROM Customer
FOR XML PATH('')
-- This will result one column with a value like this: 1 2 3 4 5 6 7 8

-- And to get the column as part of some other query:
SELECT CustomerID,
       (SELECT OrderID AS 'data()'
       FROM Order O WHERE O.CustomerID = C.Customer ID
       FOR XML PATH('')) AS OrderList
FROM Customer C

-- The result of the above query will be something like this :
-- CustomerID	| OrderList
-- --------------------------------
-- 1		    | 1 2 5 9 90 200
-- 2		    | 2 7 10 22
-- 3		    | 12 17 246
-- 4		    | 83 92 1002

-- And of course we could return it as XML
SELECT CustomerID AS '@id',
       (SELECT OrderID AS 'data()'
       FROM Order O WHERE O.CustomerID = C.Customer ID
       FOR XML PATH('')) AS '@ordelist'
FROM Customer C
FOR XML PATH('customer'), ROOT('root')

-- The result of the above query will be something like this :
<root>
  <customer id="1" orderlist="1 2 5 9 90 200"/>
  <customer id="2" orderlist="2 7 10 22"/>
  <customer id="3" orderlist="12 17 246"/>
  <customer id="4" orderlist="83 92 1002"/>
</root>

If we will look at the .NET String.cs we will see the next line:

        public static readonly String Empty = "";

The above line can tell us that string.Empty is not a constant as we would like to believe but a readonly field.

The question is why, why static readonly and not a constant. The answer is in the same String.cs comments of the Empty field.

        // The Empty constant holds the empty string value.
        //We need to call the String constructor so that the compiler doesn't mark this as a literal.
        //Marking this as a literal would mean that it doesn't show up as a field which we can access
        //from native.

Now, let’s make some test.

            string EmptyValue = string.Empty;

            if (EmptyValue == "")
                // Output : Is Empty : 1
                Console.WriteLine("Is Empty : 1");

            if (EmptyValue.Length == 0)
                // Output : Is Empty : 2
                Console.WriteLine("Is Empty : 2");

            switch (EmptyValue)
            {
                case "":
                    {
                        // Output : Is Empty : 3
                        Console.WriteLine("Is Empty : 3");
                        break;
                    }
                 case string.Empty:
                    {
                        // Compilation error : A constant value is expected
                        Console.WriteLine("A constant value is expected");
                        break;
                    }
            }

            if (EmptyValue.Equals (""))
                // Output : Is Empty : 4
                Console.WriteLine("Is Empty : 4");

            if (string.IsNullOrEmpty(EmptyValue))
                // Output : Is Empty : 5
                Console.WriteLine("Is Empty : 5");

As we can see string.Empty and “” have the same behavior except the “switch” because string.Empty is not a constant.

And of course the most important question – is there a performance differences between the two ? The answer is – Yes, but minor.
Lets see some results :

           // Execution Time : 2144ms
            for (int n = 0; n < 100000000; n++)
            {
                if (TestValue == string.Empty)
                    t = 1; //"For test purposes only..."
            }

            // Execution Time : 2211ms
            for (int i = 0; i < 100000000; i++)
            {
                if (TestValue == "")
                    t = 2; //"For test purposes only..."
            }

We can see from the results that the comparison with string.Empty is a little bit faster but it's negligible.

One of the advantages of using "" is that it's in some cases it can be optimized by the compiler before the JIT. For example if you will run the same iteration while comparing ""==null the whole block will be removed by the optimizer.

So, use what ever you like, you'd probably won't see the difference.

Well, let’s make some order in that.

protected
A protected member is accessible within its class and by derived classes.

internal
Internal types or members are accessible only within files in the same assembly.

protected internal
Access is limited to the current assembly or types derived from the containing class.
* protected internal is the only access modifiers combination allowed for a member or a type.

So, as we can see “protected internal” can be used in the same assembly or types derived from the containing class in any assembly.

It means that we can access a “protected internal” method by accessing any instance of it’s class in the same assembly, in any class in different assembly which derives from the class, but we won’t be able to access the method by accessing an instance of it’s class in different assembly.

// Assemby : A
namespace AssemblyA
{
    public class A
    {
        protected internal string SomeProtectedInternalMethod() {
            return "SomeValue";
        }
    }

    public class A2 : A
    {
        public string SomeMethod() {
            // We can access the method because
            // it's protected and inherited by A2
            return SomeProtectedInternalMethod();
        }
    }

    class A3 : A
    {
        public string SomeMethod()
        {
            A AI = new A();
            // We can access the method through an instance
            // of the class because it's internal
            return AI.SomeProtectedInternalMethod();
        }
    }
}

// Assemby : B
using AssemblyA;
namespace AssemblyB
{
    class B : A
    {
        public string SomeMethod() {
            // We can access the method because
            // it's inherited by A2
            // despite the different assembly
            return SomeProtectedInternalMethod();
        }
    }

    class B2
    {
        public string SomeMethod()
        {
            A AI = new A();
            // We can't access the method
            // through the class instance
            // because it's different assembly
            return AI.SomeProtectedInternalMethod();
        }
    }
}

So, if we will try to compile AssemblyB we’ll get an error in line 23 that says : AssemblyA.A.SomeProtectedInternalMethod()’ is inaccessible due to its protection level

I hope this explains once and for all the meaning of “protected internal” access modifier.

    // Question #1
    class Program
    {
        static void Main(string[] args)
        {
            int i = 13;
            string Result = B.Get(i);
            Console.WriteLine(Result);
        }
    }

    public class A
    {
        public static string Get(int Value) {
            return "A";
        }
    }

    public class B : A
    {
        public static string Get(float Value)
        {
            return "B";
        }
    }

    // Question #2
    class Program
    {
        static void Main(string[] args)
        {
            int i = 13;
            string Result = B.Get(i);
            Console.WriteLine(Result);
        }
    }

    public class B
    {
        public static string Get(float Value)
        {
            return "B";
        }

        public static string Get(int Value) {
            return "A";
        }
    }

What will be the result of the above code parts ?