Task-based Asynchronous Pattern

Here's a simple implementation of task-based asynchronous pattern

using System;
using System.Windows.Forms;
using System.Threading;
using System.Threading.Tasks;

namespace TestAsync
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        // inherently synchrononous operation
        public int ComputeSomething(int n)
        {
            // Problem is O(N)

            while (n-- > 0)
                Thread.Sleep(1000);

            return 7;
        }

        // Wrap the synchronous operation on Task-based Async Pattern to make the operation operate asynchronously
        Task<int> ComputeSomethingAsync(int n)
        {
            Task<int> t = new Task<int>(() =>
                {
                    return ComputeSomething(n);
                });

            t.Start();
            return t;
        }



        private void button1_Click(object sender, EventArgs e)
        {
            // instead of doing things synchronously
            if (false)
            {
                int n = ComputeSomething(10);
                MessageBox.Show("Returned value is " + n.ToString());
            }

            // do things asynchronously instead
            if (true)
            {
                Task<int> t = ComputeSomethingAsync(10);
                t.ContinueWith(x =>
                {
                    if (x.IsFaulted)
                    {
                        MessageBox.Show(x.Exception.Message);
                    }
                    else
                    {
                        MessageBox.Show("Returned value is " + x.Result.ToString());
                    }

                });
            }

        }//button1_Click


    }//class Form1
}

For asynchronous operation, TAP asynchronous design pattern is easier to use than BeginXXX, EndXXX, IAsyncResult combo async pattern

On next C# version(C# 5), making routines asynchronous will be a lot easier with its built-in await and async functionality

string.Empty vs ""

Regarding string.Empty vs "". string.Empty is performant(using this word comes with a risk of sounding like a sales brochure) than "", but that is only prior .NET 2.0. Prior .NET 2.0 (i.e. 1.1 and 1.0), every literal strings even they are similar, are allocated their own slots in memory, hence declaring "" once and pre-assigning it in string.Empty is warranted and thus faster and saves space than merely using "" strings everywhere. string.Empty is faster than "", but that is on .NET 1.0 and 1.1 only

But on .NET 2.0 onwards, every similar literal strings are interned.

Interning is the process of looking at all similar string literals in an executable and making them point to one memory address only, i.e. all similar string literals share the same address.

On .NET 2.0 and onwards, every similar empty strings(any similar strings for that matter, even non-empty ones) doesn't allocate new memory

string.Empty is still nice, it is readable and one can easily glean the code intent. But that is debatable, I believe that "" is more readable than string.Empty. In the same vein that 0 is readable than int.Zero. Any takers of this code? if(i == int.Zero)

And string.Empty could be slower than "" on 2.0 and onwards, string.Empty is another indirection during runtime. "" is just that, a memory address has just one location, never-changing.

using System; 

namespace StringInterning 
{ 
    class Program 
    { 
        unsafe static void Main(string[] args) 
        { 
            string s = "Hello"; 
            string t = "Hello"; 
             

            fixed (char* dst = s) 
            { 
                dst[0] = 'M'; 
                dst[1] = 'i'; 
            } 
             

            Console.Write("Enter greeting: "); 
            string greet = Console.ReadLine(); // try to enter the word: Hello 
            Console.WriteLine(); 


            if (greet == "Hello") 
                Console.WriteLine("Friendly"); // if you enter Hello for greet, this will not print. funneh :D 
            else 
                Console.WriteLine("This will print instead"); // this will print instead 

            Console.WriteLine("S {0}", s); // will print Millo 
            Console.WriteLine("T {0}", t); // will print Millo 
            Console.WriteLine("Hey {0}", "Hello"); // will print Hey Millo 

            Console.WriteLine(); 

            fixed (char* dst = " ") 
            { 
                *dst = 'Y'; 
            } 

            Console.WriteLine("Value of {0}{1}", " ", " "); // this will print YY. funneh :D 


            Console.ReadLine(); 
        } 
    } 

} 

Enter greeting: Hello 

This will print instead 
S Millo 
T Millo 
Hey Millo 

Value of YY 

---

And the great Jon Skeet uses.., surprise! --> ""

here's his rationale:

http://stackoverflow.com/questions/263191/in-c-should-i-use-string-empty-or-string-empty-or/263257#263257


We can't even use string.Empty on parameters, it will not compile:

public static void Funny(string message = string.Empty) // this will not compile. must use ""
{
    Console.WriteLine("Hahah {0}", message);
}

string.Empty can't even be used on attributes, it will not compile:

[Label(string.Empty)] // this will not compile. must use ""

string.Empty can't even be used on switch, it will not compile:

string s = Console.ReadLine();
switch (s) 
{
case "Hahah":
    break;

case string.Empty: // this will not compile too. must use ""
    break;
}

For those who are dogmatic on using string.Empty. Though it's not your problem, it's the language designer's choice, you have to do some concessions and you shall just write "" anyway.



Perhaps programmers using string.Empty love to code so much ツ

C# is a very type-safe language

In C#, type-safety is not only a compile-time thing, it's also type-safe during runtime, this will not compile:

Student s = new Person();

This is not allowed in C++ too, C++ is type-safe too, albeit not as strongly type as C#, which we will discuss later what makes C++ type-safety a bit weaker, this will not compile too:

Student *s = new Person();

Now, let's try to coerce C# to point Student object to Person object, this will compile:

Student s = (Student) new Person();

Let's try the same with C++, this will compile too:

Student *s = (Student *) new Person();

The two codes above, though both will compile, that is where C# and C++ diverge, not only in terms of type safety but also in terms of runtime security(which we will discuss immediately). During runtime, C# will raise an error; whereas C++ will happily do your bidding, it will not raise any error. Now, how dangerous is that kind of code?


Imagine this is your object:

class Person
{
 public int favoriteNumber;
}

class Student : Person
{
 public int idNumber;
}

If you allocate memories for Person, for example, if it so happen that the locations of these memory allocations are adjacent to each other: Person pA = new Person(); Person pB = new Person(); If the runtime will let us point Student s to Person pA, there's a higher chance that the assignments on fields of Student s could overwrite the content of adjacent Person pB object.



To make the principle more concrete, let's do it in a language which leniently allow that sort of thing.

#include <cstdio>


class Person
{
public:
   int favoriteNumber;

};


class Student : public Person
{
public:
 int idNumber;
};


int main()
{
 
 Person *p = new Person[2];
 p[0].favoriteNumber = 7;
 p[1].favoriteNumber = 6;

 printf("\nP1 Fave# %d", p[0].favoriteNumber);
 printf("\nP2 Fave# %d", p[1].favoriteNumber);


 void *objek = (void *) &p[0];
 // above code is equivalent to C#'s:
 // object objek = p[0];
 
 Student *s = (Student *) objek;
 // above code is equivalent to C#'s:
 // Student s = (Student) objek;
 
 
 s->idNumber = 9;  
 printf("\n\n");
 printf("\nS# %d", s->idNumber);
 printf("\nP1 Fave# %d", p[0].favoriteNumber);
 printf("\nP2 Fave# %d", p[1].favoriteNumber);


 p[1].favoriteNumber = 8;
 printf("\n\n");
 printf("\nS# %d", s->idNumber);
 printf("\n\n");
  
}

The output of that code:

P1 Fave# 7
 P2 Fave# 6
 
 
 S# 9
 P1 Fave# 7
 P2 Fave# 9
 
 
 S# 8

Can you spot the anomalies? We assign a value 9 to student's idNumber, yet P2's favoriteNumber also changes. We changed the P2's favoriteNumber, yet student's idNumber also changes. Simply put, Student's field(s) overlap other objects' field(s) location , so that's the problem if a language allows arbitrary pointing of objects to any object type.

.........Person
[0xCAFE] (favoriteNumber) : 7
[0xCAFF] (favoriteNumber) : 6

Student points to first person(which has an adjacent person):

.........Person                Student
[0xCAFE] (favoriteNumber) : 7  (favoriteNumber)
[0xCAFF] (favoriteNumber) : 6  (idNumber)

If a language allows pointing Student to a Person's memory location(0xCAFE), what will happen if we change the value of Student's idNumber? the adjacent second person's favoriteNumber will be changed too, an unintentional corruption of memory. Worse yet, if this is done on purpose, it is a potential security problem. Think if Student can point to any object type, the idNumber could be used to peek other object's contents, even those other object's fields are private