I was happy programming with (generic) constraints which overtook the limitations in C++ templates. However, constraints need to be less restrictive. What is that? Let us say I want a helper method that checks a condition and throws an exception if the check failed. So that would be...

void TestCondition(bool condition, string msgText)
{
    if (!condition)
    {
        throw new Exception(msgText ?? "Unknown Error");
    }
}

I like it; it is cute. However, not at all times would the caller be happy with throwing System.Exception. Since the above method can be used in a wide variety of situations, it would make sense for the caller to specify the type of exception he would like to throw. It would be classic if the above is made generic taking type T and constraining it be to a derivate of System.Exception. Sounds great and so…

void TestCondition2<T>(bool condition, string msgText) where T : Exception
{
    if (!condition)
    {
        throw new T(msgText ?? "Unknown Error");
    }
}

The above code is dream still; it will result in a compilation error. Although generics offers the constraint that T should be a derivate of System.Exception, it does not relax it specifying the constructor it would like to use from T; in other words, there is constraint mandating T to expose a default constructor but none other. So we cannot offer the above facility with elegance (or performance?). There is the ugly way. How?

void TestCondition3(bool condition, Exception ex)
{
    if (!condition)
    {
        throw ex;
    }
}

Seems good? Partly No. If TestCondition2 was possible, the exception object(s) would be created only if the condition failed, while TestCondition3 meeting our purpose creates exception objects irrespective of the condition; and gets thrown if the condition fails.

So when are (generic) constraints going to be relaxed? C# 5.0?

Senthil has left us thrilled in his new post, and also inspired me to write about the topic. Although, anonymous delegates have become a mundane stuff amongst programmers, there is still these subtle stuff left unexplored. Alright, let us try to answer Senthil's question before he unravels the mystery in his next post.

A delegate is identified by its target. The target is the method to be executed on a delegate invocation and its associated instance or type. If the target is an instance method, the delegate preserves the target method pointer and the object instance. If the target is a static method, the delegate preserves the target method pointer and the type to which it belongs. So when a code like the one below to register a method to an event (or multicast delegate) is executed, a delegate object (EventHandler here) with the target information embedded is created and added to the invocation list of the event (or multicast delegate, KeyPressed here).

class SomeForm
{
	private Control control = new Control();

	public void OnFormLoad(object sender, EventArgs args)
	{
		control.KeyPressed += new EventHandler(OnKeyPressed);
	}
	
	// Rest of the code omitted to be succinct
};

Likewise, when unregistering the method handler, a new (EventHandler) delegate object is created with the same target information as above. As said earlier, a delegate is identified by its target. In other words, the Equals override on the delegate uses the target information for comparing two delegate objects. Hence in the following code that unregisters the method handler, the invocation list is searched for a delegate instance with the specified target information (Method: OnKeyPressed, Instance: SomeForm instance).

In the case of anonymous delegates, the compiler transforms the inline method code into a

• static method, if the inline method code does not use any of the class's instance members or local variables or if it uses only the static members of the class.
• instance method, if the inline method code uses at least one class member, any or no static members, and no local variables.
• class with a method that represents the inline method code, if the inline method code uses local variables no matter whether it uses the class members or not.

Those might not be the extensive set of rules but sure are enough for our discussion. Given the following questionable code,

public EventHandler IfEnabledThenDo(EventHandler actualAction)
{
	return (sender, args) => { if (args.Control.Enabled) { actualAction(sender, args); } };
}

public void Initialize()
{
	control.KeyPressed += IfEnabledThenDo(control_KeyPressed);
}

public void Destroy()
{
	control.KeyPressed -= IfEnabledThenDo(control_KeyPressed);
}

we realize, without doubt, that the anonymous delegate (returned by IfEnabledThenDo) would be transported into a compiler generated anonymous class. Later when IfEnabledThenDo is called for registering\unregistering the method handler, an instance of anonymous class is created and the (EventHandler<Control.ControlEventArgs>) delegate is returned. And here lies the subtlety. Although the delegate from IfEnabledThenDo targets the method inside the anonymous class, the instance preserved as a part of the target information are different during registration and un-registration. In other words, the target method of the delegate returned by IfEnabledThenDo belong to different instances of the anonymous class. Hence the pretty code to unregister the (key pressed) method handler would not be actually unregistering since there would be a delegate previously registered in the invocation list of the (KeyPressed) event with the target instance same as the one used in the unregistration line of code. Very subtle!

Usually the hand written code tends to keep the registration and unregistration of the method handlers in the same class and so belong to the respective instances. Not so when you like watching the compiler magic.

Let us wait and see what Senthil says.

Sanjeev wondered why should an event decalred in an interface be declared in the implementation class too. For instance if we have an interface ISample as follows:-

public delegate void DataChangedDelegate(int dataID, object newData);
public interface ISample
{
    event DataChangedDelegate dcDelegate;
    void SomeMethod(); 
    bool SomeMethod(int x);
}

and a class that implements ISample (implicitly):-

public class SampleImpl : ISample
{
    public SampleImpl()
    {
    }

    #region ISample implicit implementation

    // Why is this required to be done?
    public event DataChangedDelegate dcDelegate;

    public void SomeMethod()
    {
    }

    public bool SomeMethod(int x)
    {
        return x >= 0 ? true : false;
    }

    #endregion
}

While we define the implementation of the methods from ISample in SampleImpl, we dont do anything (special) to implement the event. So why should SampleImpl simply declare the event once again? Of course, it is convince to compiler from spitting errors.

It is time to know what is an event? The event keyword when decorated for a delegate declaration ensures that only the class\struct in which the event is declared will be able to raise event, irrespective of its access levl. In other words, only the owning class\struct will be able to call the subscribers. So that will prevent anybody outside the declaring class to misuse the delegate - raise false events - especially when the delegate is declared public.

Good, but still there is a way to tamper the delegate. Anybody could add or especially remove the subscribers from the delegate (when it is exposed public). The event keyword does more than preventing unauthorised use of the delegate to raise events. It is a compiler acronymn for methods by which handler targets can be added and removed from the delegate. We can say it is analogous to the properties which provide get and set methods. An event is not like an ordinary member declaration - int, float or delegate for that matter, and interfaces cannot bear member declarations.

In essence, an event declaration in the interface opens up during compilation as follows:-

// add and remove are like get\set in a property.
event DataChangedDelegate dcDelegate { add; remove; } 

The add and remove have to implemented in the derived class. Declaring the event in the derived class instructs the compiler to generate default implementation for add and remove methods, something like what the automatic properties do. If one wants to take control of adding and removing handlers with some custom logic, he/she can do so by explicitly implementing add\remove methods.

private DataChangedDelegate dcSubscribers;
public event DataChangedDelegate dcDelegate
{
    add
    {
        if (value == null)
        {
            throw new Exception("Specified null event handler");
        }

        lock (dcSubscribers)
        {
            dcSubscribers += value;
        }
    }
    remove
    {
        if (value == null)
        {
            throw new Exception("Specified null event handler");
        }

        lock (dcSubscribers)
        {
            dcSubscribers -= value;
        }
    }
}

And SomeOtherMethod in the derived class could fire the event.

public bool SomeOtherMethod(int x)
{
    DataChangedDelegate tempDC = dcSubscribers;
    if (tempDC  != null)
    {
        tempDC(x, DateTime.Now);
    }

    return x > 0 ? true : false;
}

So that's why it is necessary to declare an event member when deriving from an interface.

Let us read some code:-

int SomeMethod()
{
    int num = 1;

    try
    {
        num = 5;
        return num;
    }
    finally
    {
        num += 5;
    }
}

What is the return value of SomeMethod? Some anonymous guy asked that question in the code project forum, and it has been answered. I am writing about it here because it is interesting and subtle. One should not be surprised when people misinterpret finally. So let us take a guess, 10 (i = 5, then incremented by 5 in the finally block).

class Num
{
    public int _num = 0;
};

int SomeMethod()
{
    Num num = new Num();

    try
    {
        num._num = 5;
        return num._num;
    }
    finally
    {
        num._num += 5;
    }
}

So in the above case, the return value is still 5, but the Num._num would have been incremented to 10 when SomeMethod returns. So reflecting shows that our code is transformed as follows by the compiler, where the CS$1$0000 is our return value.

private static int SomeMethod(Num num)
{
    int CS$1$0000;
    try
    {
        num._num = 5;
        CS$1$0000 = num._num;
    }
    finally
    {
        num._num += 5;
    }
    return CS$1$0000;
}

Given that we have clarified ourselves about finally, we should be writing the code as transformed by the compiler because returning from try and catch blocks is not a good practice.

I would not want to write chunks of code to spawns threads and perform many of my background tasks such as firing events, UI update etc. Instead I would use the System.Threading.ThreadPool class which serves this purpose. And a programmer who knows to use this class for such cases would also be aware that the tasks queued to the thread pool are NOT dispatched in the order they are queued. They get dispatched for execution in a haphazard fashion.

In some situations, it is required that the tasks queued to the thread pool are dispatched (and executed) in the order they were queued. For instance, in my (and most?) applications, a series of events are fired to notify the clients with what is happening inside the (server) application. Although the events may be fired from any thread (asynchronous), I would want them or rather the client would be expecting that the events are received in a certain order, which aligns with the sequence of steps carried out inside the server application for the requested service. So sequential execution of the queued tasks is not something one must not wish for.

Enough talking.......eat code.

using System;
using System.Collections.Generic;
using System.Diagnostics;

namespace System.Threading
{
   struct ThreadPoolTaskInfo
   {
      public readonly WaitCallback CallbackDelegate;
      public readonly object State;

      public ThreadPoolTaskInfo(WaitCallback wc, object state)
      {
         Debug.Assert(wc != null);
         CallbackDelegate = wc;
         State = state;
      }
   }

   class OrderedThreadPool
   {
      private Queue workItemQ = new Queue();

      public void QueueUserWorkItem(WaitCallback wcbDelegate, object state)
      {
         lock (workItemQ)
         {
            workItemQ.Enqueue(new ThreadPoolTaskInfo(wcbDelegate, state));

            if (workItemQ.Count == 1)
            {
               ThreadPool.QueueUserWorkItem(LoopWork);
            }
         }
      }

      private void LoopWork(object notUsed)
      {
         WaitCallback wcb = null;
         object state = null;

         lock (workItemQ)
         {
            if (workItemQ.Count == 0)
            {
               return;
            }

            ThreadPoolTaskInfo tptInfo = workItemQ.Dequeue();
            state = tptInfo.State;
            wcb = tptInfo.CallbackDelegate;
            Debug.Assert(wcb != null);
         }

         try
         {
            wcb(state);
         }
         finally
         {
            ThreadPool.QueueUserWorkItem(LoopWork, notUsed);
         }
      }
   }
}

Let us take a look at the following piece of code:-

public void Operate(IList iList2)
{
    iList2 = new List();
    iList2.Add(1);
    iList2.Add(2);
    iList2.Add(3);
}

public static void Main()
{
    IList iList= new List();
    iList.Add(10);

    Operate(iList);

    Console.WriteLine(iList[0].ToString());
}

Be thinking about what would the above program print to the console ? And that is what we are going to talk about in this post - simple but subtle.

I saw this code at CodeProject discussions. The author was confused with why was the program printing 10 instead of 1. I am writing about this since the 'gotcha' was not highlighted in the discussion.

Hope that was fun !!!

Consider this:-

class CmdBase
{
	public char ReturnValueFromBase()
	{
	}
}

class ReadCmd : CmdBase
{
	// No time for ctor coding

	public bool ReturnValueFromRead()
	{
	}
}

class WriteCmd : CmdBase
{
	// No time for ctor coding

	public int ReturnValueFromWrite()
	{
	}
}

// And imagine exactly 212 other such commands, just kidding; the above two would do fine for now.

Now let us say we want to write a method which could execute any given command (a derivate of CmdBase), and as you can see must be to retrieve the command specific return value (via the ReturnValeFromXXX method). So...

T Execute<T>(T cmdObj) where T : CmdBase
{
	// Execute the command by any way you like
	return cmdObj;
}

You can call Execute in one of the following ways:-

Execute<ReadCmd>(new ReadCmd(/*parameters*/).ReturnValueFromRead();

or

Execute(new ReadCmd(/*parameters*/).ReturnValueFromRead();

Is there any difference in the above two ways ? Ideally, none. Wierd that the intellisense does not infer the exact type for the second way; instead assumes the type passed as CmdBase. But the code compiles and executes fine (as written and as expected). So is that a bug in the intellisense or is that intentional ?

Every time I find it hard with these Microsoft guys. They are smart, I agree. But frequently they miss out vital features in the products they deliver. Something like the picture box control without the facility to view the image with scrolling. I had this situation where I needed a (picture box like) control which must be able to display images in one of the two modes - Blown-up or Full Image.

So what are these two modes ? That is a story a bit big for this post. I have posted an article in Code Project that talks about our control Scrollable Image Viewer control. Go have a look at it and sure you may find it useful in your applications too. In that case, you are free to use and distribute (CPOL). Oh......bugs are your burden.

Can you imagine a life without friends ? I would say it would be miserable. It is a great deal of trust and sharing; you expose your private stuff and she too does, you know it is great. That makes tough tasks come down low. But it is your responsibility to choose who your friends are, else you are going to hurt yourself. Hey, I am talking C++. Friend functions and classes are real sweet, but you have to be careful in your judgment.

Ok, why are we talking this ? It is a common scenario where there is a class which acts as a manager and manages instances of an other class. Need an example, imagine this - Let us say that we have an Employee class which describes an employee (ID, Name, Salary, DOB etc). At first look, we can easily say that his ID is his private stuff, and also it must be unique. So if we are creating a new instance of an Employee, it must be ensured that the ID is indeed unique. That means that just a public method on Employee to set the ID or a one time set in the Employee constructor is not enough. So we can have a Supervisor class that has the manages the list of employees. Too much talk, let us see code with Supervisor being friendly with the Employee.

// Forward Declaration
class Supervisor;

class Employee
{
private: int _id;
private: std::string _name;
private: float _salary:
private: DateTime _dob;
private: int _designationLevel;

private: Employee(int id,
            const std::string& name,
            const DateTime& dob,
            int designationLevel)
         {
            this->_id = id;
            this->_name = name;
            this->_designationLevel = designationLevel;
            this->_salary = designationLevel * 1000;
            this->_dob = dob;
         }

         // private set methods for the data members
private: void ChangeName(const std::string& newName)
         {
            this->_name = newName;
         }

private: void UpdateDesignation(int dLevel)
         {
            this->_designationLevel  = dLevel;
            this->_salary = dLevel * 1000;
         }

         // private get methods for the data members
public: int ID() const { return this->_id; }
public: int Name() const { return this->_name; }
public: DateTime DOB() const { return this->_dob; }
public: int DesignationLevel() const { return this->_designationLevel; }
public: float Salary() const { return this->_salary; }

        friend class Supervisor;
};

class Supervisor
{
public: std::list<Employee*> employeeList;

public: Employee* AddNewEmployee(const std::string& name, int designationLevel)
        {
           int id = GenerateUinqueID();
           return new Employee(id,
              name,
              "12-JUNE-1980",
              designationLevel);
        }

public: void ChangeEmployee(const Employee& emp, const std::string& newName)
        {
           std::list<Employee>::iterator iter = employeeList.end();
           iter = std::find(employeeList.begin(), employeeList.end(), emp);

           if (iter != employeeList.end();)
           {
              (*iter)->ChangeName(newName);
           }
        }

public: void Promote(const Employee& emp)
        {
           std::list<Employee>::iterator iter = employeeList.end();
           iter = std::find(employeeList.begin(), employeeList.end(), emp);

           if (iter != employeeList.end();)
           {
              (*iter)->UpdateDesignation(emp->DesignationLevel()++);
           }
        }
};

That is the not the best code you have ever seen, but let us stick to the theme of the post - friends ! So the Supervisor is a friend of Employee and so is it the only privileged one to create and modify the Employee class. Most important (in many cases), an instance of Employee cannot be created by anybody, say with duplicate or invalid IDs.

When C++ is cursed for the friend facility, which some people think is a tweak or a loop hole for the data privacy, I would say that it is a finely thought one and must be used with judgement. It is not for the weak hearted ones. I have used a lot in many of my projects with care, caution and rationale.

So, there is no friend facility in C#. Atleast, I am not aware of one such. My code looks horrible for a design discussed above. So is there an alternative approach (of design) in C# for the above mentioned problem ?

The question is open to all. Got any idea or a solution ?

Imagine a class written as shown below:-

public partial class HardwareUI : UserControl
{
   private bool advancedOpen = false;
   private int CollapsedContainerWidth = 170;
   private int ExpandedContainerWidth = 510;

   // Default Ctor
   public HardwareUI() : this(this.CollapsedContainerWidth, this.ExpandedContainerWidth)
   {
   }

   // 2Arg Ctor
   public HardwareUI(int collapsedParentHeight, int ExpandedContainerWidth)
   {
      InitializeComponent();

      if (collapsedParentHeight > 0)
      {
         this.CollapsedContainerWidth = collapsedParentHeight;
      }

      if (ExpandedContainerWidth > 0)
      {
         this.ExpandedContainerWidth = ExpandedContainerWidth;
      }
   }

// Other Code
}

I have shown that part of the class that is pertaining to the theme of this post. So hold on a while if you feel that the class is inadequate or wrongly written.

The compiler spat an error - "Keyword 'this' is not allowed in the current context". That is what I am suprised about. Why cannot I use the 'this' in the ctor ? The following two things should have been done (in order of apperance) when the execution reaches the ctor :-

// NEW Default Ctor
public HardwareUI() : base(this.CollapsedContainerWidth, this.ExpandedContainerHeight)
{
    InitializeComponent();
}

// NEW 2Arg Ctor
public HardwareUI(int collapsedParentHeight, int ExpandedContainerWidth)
    : base(this.CollapsedContainerWidth, this.ExpandedContainerHeight)
{
   InitializeComponent();

   if (collapsedParentHeight > 0)
   {
      this.CollapsedContainerWidth = collapsedParentHeight;
   }

   if (ExpandedContainerWidth > 0)
   {
      this.ExpandedContainerWidth = ExpandedContainerWidth;
   }
}

So the <> is an ease of syntax and does not compromise the type and identity.

There is nothing special about this but that after using templates for a while, generics seems to help avoid reiterating the type information. Type and Identity are considered very sacred in the managed world. May be that is special and its manifestation is well seen through this nifty syntax for generics.