Genrics magic !!!!

After a long time…I found something to write about. Consider the following code snippets ….
public class A
{
public void N()
{
Console.WriteLine(typeof(T).ToString());
}
public class B : A
{
public void M()
{
Console.WriteLine(typeof(T).ToString());
}
public class C : B{ }
}
}
class MainClass
{
static void Main()
{
A.B b = new A.B();
b.M();
b.N();

A.B.C c = new A.B.C();
c.M();
}
}

what would be output of the above code …. ??
b.M() = System.String
b.N() = System.Int32
c.M() = System.Int32

b.M() prints System.String but c.M() prints System.Int32 !!!! isn’t it interesting ?
why does it happen ? the catch is, class AString.B.C is getting inherited from AInt.B, not AString.B, because the class AStrig.B inherited from AInt, so the compiler consider B as AInt.B not AString.B ..however you can modify the hierarchy like this code public class C : AString.B, then C will be inherited from AString.B.
For understanding purpose we can exapand the code manually as follows ...

public class AInt
{
public void N()
{
Console.WriteLine(typeof(int).ToString());
}
public class B : AInt
{
public void M()
{
Console.WriteLine(typeof(int).ToString());
}
public class C : B { }
}
}

public class AString
{
public void N()
{
Console.WriteLine(typeof(string).ToString());
}
public class B : AInt
{
public void M()
{
Console.WriteLine(typeof(string).ToString());
}
public class C : B{ }
}
}

** My special thanks to Eric Lippert(works with the C# dev team)for finding time and explaining me the issue.

int[] = object OR object[]

Let ms share an interesting fact[compiler rule] of C# language, consider the following class …
class TestCSharpFacts
{
public void DoSomthing(object obj)
{
MessageBox.Show("Inside DoSomthing(object obj)" + obj.ToString());
}

public void DoSomthing(object[] obj)
{
MessageBox.Show("Inside DoSomthing(object[] obj)" + obj.Length.ToString());
}
}

Now, say you are calling DoSomething method in the following way ..

1. obj.DoSomthing(123);

2. obj.DoSomthing(new System.Int32[] { 1, 2, 3 });

In the first case we all can say the first method will be called, but guess which routine will be called in the second case, it will again call the first method, i.e. DoSomthing(object obj),

Why does it happen ? My assumption is, C# consider a ‘Value’ type array as an ‘Object’ not an ‘Array of Object’, however an ‘Array of Reference’ is considered as ‘Array of Object’, so if we do a call like the following
TestCSharpFacts[] objs = new TestCSharpFacts[4];
obj.DoSomthing(objs); C# will call the second method.

So, the rule is
a) Value type array = Object
b) Reference type array = Object[]

However, I am yet to find any Microsoft documentation on this, I am looking around for it.

Thread Priority and Process Priority

In our walk of life almost of us have done some amount of "multithreading" programming sometime or other and also there are few cases when we have set the "ThreadPrority" level to make sure that the thread gets more/less CPU.

If we look at the "ThreadPriority" enum, we can see there are 5 values ( AboveNormal, BelowNormal,Normal,Highest and Lowest ), a thread’s Priority property determines how much execution time it gets relative to other active threads in the same process, so does that mean if we set the "ThreadPriority" of a thread as "Highest" then the thread will run almost like a realtime application ?

Well NO, setting a thread’s priority to "Highest" doesn’t mean it can perform real-time work, because it’s still limited by the application’s process priority( read "BasePriority"). The Process class has a property named "BasePriority" returns a number which indicates the priority level at which the process is running.

Let us have a look at the internal mechanism, how exactly windows OS work ? the Windows 32-bit operating systems schedule threads using 32 priority levels, numbered from 0 to 31. The highest-numbered thread is processed first. As threads wait to be processed, their priority levels are increased. The base application priority determines the priority level at which threads begin.

For example if a process is running with a "BasePriority" Normal(which is the default value ) and we set the "ThreadPriority" of a thread as "Highest" then the priority level of the thread will be 9( visit this link [http://msdn2.microsoft.com/en-us/library/ms685100.aspx] to see all the combination of Process.BasePriority and Thread.ThreadPriority, it shows the scheduling priority level with respect to the Process.BasePriority and Thread.ThreadPriority ), so if there is any other thread which has higher level ( > 9 in this context), that will run first.

So, to get the expected behavior( say we want to run an application almost like a realtime application which should consume most CPU and there should not be any preempt on this thread)setting the "ThreadProperty" will not be enough, we must set the "Process.BasePriority"accordingly. To set the BasePriority of a Process we have take help of the "PriorityClass" property of the Process class( since Process.BasePriority is a readonly property ).

Sample code:
System.Diagnostics.Process p = System.Diagnostics.Process.GetCurrentProcess(); p.PriorityClass = System.Diagnostics.ProcessPriorityClass.High;

Alternatively we can do the above thru TaskManager also.

Note: As per MSDN documentation we must not set the ProcessPriority as "Realtme" cause that will preempt all other processes( even OS process )which will lead to a machine hang, may be the keyboard and mouse will not work so there should not be any other option other than a hard booting.

Why 'Value' types does not support inheritance ??

Why 'Value' types does not support inheritance ??

Few days back one of my friend has asked me this question, that time I couldn't think of any good answer that moment. Later I did some research and found that C# compiler( VB complier will do the same ) compile a structure as a "SEALED" class , which is why we can not inherit any "Structure"( read Value type ), now it raise another question why does the compiler compile it as a "SEALED" class ? is it by design ? what are the problems would happen if the compiler compile it as a normal(non-sealed in this context) class ?

After studying article of Jeffrey Ritcher, Tanj Bennett and others and discussing with my friends like Pal b and Richard and compiling my own thought with that ... here is what came out ...

It is not a limitation of C# or VB compiler, it's a limitation of .NET CLR. Though all data types (Reference-types as well as Value-types) in .NET are derived from the ultimate base class “Object”, structure in .NET has one very important advantages over class. I think that is the one of main reasons to introduce the concept of structure in .NET. And that is “Structure is lighter-weight than class”. Light-weight structure gives you better performance than class if you use it appropriately. To keep this “light-weightiness” behaviour of structure, .NET CLR considers it as a sealed class (actually all value-types are sealed class) - no object identity, no overheads for vptr (method pointer which is required to call virtual methods).

You might ask, then, how does structure support overriding methods (ToString, Equals, etc) of base class “Object”. It allows because in this case vptr will be inside “Object” class, not in structure. So, what's your take buddy ?