Extension Methods – A Polished C++ Feature !!!

Extension Methods is an excellent feature in C# 3.0. It is a mechanism by which new methods can be exposed from an existing type (interface or class) without directly adding the method to the type. Why do we need extension methods anyway ? Ok, that is the big story of lamba and LINQ. But from a conceptual standpoint, the extension methods establish a mechanism to extend the public interface of a type. The compiler is smart enough to make the method a part of the public interface of the type. Yeah, that is what it does, and the intellisense is very cool in making us believe that. It is cleaner and easier (for the library developers and for us programmers even) to add extra functionality (methods) not provided in the type. That is the intent. And we know that was exercised extravagantly in LINQ. The IEnumerable was extended with a whole lot set of methods to aid the LINQ design. Remember the Where, Select etc methods on IEnumerable. An example code snippet is worth a thousand words:-

static class StringExtensions
{
	///
	/// 'this' decorator signifies that this is an extension method.
	/// It must be appear only on a public static method.
	/// Such a method is added to the public interface of the type following
	/// the 'this' decorator.
	///
	public static int ToInteger(this string s)
	{
		return Convert.ToInt32(s);
	}

	public static string Left(this string s, int position)
	{
		return s.Substring(0,position);
	}

	public static string Right(this string s, int position)
	{
		return s.Substring(s.Length - position);
	}
}

You might be aware of all this hot news. But our topic of the day is neither Extension Methods nor LINQ. It is something that dates back to C++. And you will see at the end of this post that extension methods are a polished version of a C++ principle. Ok, let us try to read some code:-

int Add(SomeClass& sc, int x)
{
   // Let us get to here a little later.
}

class SomeClass
{
private: int m_nNum;
public: void SomeMethod(int n);
public: int Num const
   {
      return this->m_nNum;
   }
};

The code is simple – We have a class called SomeClass and a global function. The global function takes a SomeClass instance by reference and an integer by value. The intent of the function is to add x with m_nNum. But whether to save it to m_nNum or just return is a topic we will deal in a little while. But do we understand that the Add function and SomeClass are closely related ?

There are two principles to know in C++ to understand the relation.

Interface Principle

For a class X, all functions, including free functions, that both (a) “mention” X, and (b) are “supplied with” X are logically part of X, because they form part of the interface of X.

* Supplied with X means that the function is provided (distributed with) in the same header file as X.

So now, Add mentions SomeClass and (to keep the discussion short assume that it) is supplied with SomeClass. If that, then Add is a part of the public interface of X. That should convince you.

Koenig Lookup

When an unqualified name is used as the postfix-expression in a function call, other namespaces not considered during the usual unqualified lookup may be searched, and namespace-scope friend function declarations not otherwise visible may be found. These modifications to the search depend on the types of the arguments. Those are lines from the C++ standard and must be tough to understand like the verses in the Bible. So let us talk our language to understand that:

namespace CPP
{
     class SomeClass { };
     void Foo(SomeClass);
}

CPP::SomeClass sc;

void main() 
{
     Foo(sc);
}

Will you be still surprised that Foo(sc) call will link to the CPP::Foo ? Don’t be. That is what the cryptic lines above talks about. Ok, one more example:

namespace CPP
{
   class SomeClass { };
}

void Foo(CPP::SomeClass);

void main()
{
   CPP::SomeClass sc;
   Foo(sc); // Got it ?
}

So now down to my point, Extension Methods is a polished version of the Interface Principle (or Koenig Lookup) in C++. The facility has been in C++ for a long time but not sure if exercised well (and wisely). Had the intellisense been intelligent enough, C++ would claimed it a mighty feature. Since the C++ IDE has been the same sucking way for a long time now, C++ got the wrong outlook – a hard programming language.

Hey C#, No hard feelings. It is just a perspective. Either way, My compiler compiles your compiler.

Advertisements

The Surprising Finalize Call !!!

Guess the output of the following program:-

class SomeClass : IDisposable
{
public SomeClass()
{
Trace.WriteLine("SomeClass - Attempting instance creation");
throw new Exception("Ohh !!! Not Now");
}

public void Dispose()
{
Trace.WriteLine("SomeClass::Dispose");
}

~SomeClass()
{
Trace.WriteLine("SomeClass::Finalizer");
}
}

int Main(string args[]){
try{
SomeClass sc = new SomeClass();
}catch(Exception ex){
Trace.WriteLine("Main - {0}", ex.Message);
}
}

This will be the output of the program:-

SomeClass - Attempting instance creation
Ohh !!! Not Now SomeClass::Finalizer

If you are surprised with the last line of the output, that will be the intent of our discussion. In the .NET [managed] world, the garbage collector is entirely responsible for memory management – allocation and deallocation. In C#, an instance of a class is created using the new keyword. When an instance creation is requested, first memory for the instance is allocated followed by a call to the [appropriate] constructor of the class.

To explain the surprising output, the constructor is called after the memory is allocated by the GC. When the constructor throws exception, the object or resource creation is interrupted but the memory cannot deallocated instantly since the GC is entirely responsible for memory deallocation. The GC follows a complex and non-deterministic style for deallocating or reclaiming an allocated chunk of memory. The finalizer method is the last call made on a managed object just before reclaiming memory. Hence in the above case, the finalizer is being called before reclaiming the memory allocated for an instance of SomeClass.

The above behaviour is very much different from the unmanaged C++ where when the instance creation is interrupted [by throwing an exception], the allocated memory is deallocated and reclaimed instantaneously. Also the destructor is not called in this case.

P.S: Thinking of a more detailed post on non-deterministic destruction.

Overloading……A Matter Of Taste !!!

This was a pretty interesting discussion about method overloading in the managed world. As the discussion says that the overloading is a matter of taste. It seems that the method overloading in the managed world, indeed, is a matter of taste. Sad BUT True !!! But on the contrary, it must have been a [strict] rule. Overloading might be exhibited differently by each language in the unmanaged world. But as far as .NET goes, it must have been made a standard specification. Pardon me, if there is one.

As it was pointed out in the discussion, how do we define the behaviour in the case where we derive classes across assemblies developed in another .NET language ?

As far traditional C++ goes, the overloaded method resolution starts from the derived but does not have strict type checking eg. for numeric types]. And the point to note is that only the method in the derived class with the exact prototype as the base is considered the overload. Ofcourse, C++ is not as much type safe as C#. This is taken care in C# by the override keyword which allows only the exact prototypes to be involved in overloading. And at times explicit casting is required unlike in C++.

But in the case of C#, the first principle observed in overloading is to avoid it. Pretty confusing, huh? Take a look at the example below:-


namespace Samples.MyConsole
{
class Parent
{
public void Foo()
{
Console.WriteLine("Parent.Foo");
}
}

class Child : Parent
{
public void Bar()
{
Console.WriteLine("Child.Bar");
}
}

class Base
{
public virtual void XYZ(Child c)
{
c.Foo();
c.Bar();
}
}

class Derived : Base
{
public virtual void XYZ(Parent p)
{
p.Foo();
}

public override void XYZ(Child c)
{
base.XYZ(c);
}
}

class User
{
public static void SomeMethod()
{
Child c = new Child();
Parent p = c as Parent;

Derived d = new Derived();
Base b = d as Base;

Console.WriteLine("Playing with Derived");
d.XYZ(c);
d.XYZ(p);

Console.WriteLine("\nPlaying with Base");
b.XYZ(c);
b.XYZ(p as Child);
}
}
}


Here is the output at the console:-

Playing with Derived
Parent.Foo
Parent.Foo

Playing with Base
Parent.Foo
Child.Bar
Parent.Foo
Child.Bar

You would have guessed the surprise that you are about to experience. Yes, d.XYZ(c) calls the Derived.XYZ(Parent p), and not the Derived.XYZ(Child c) which is a better match. It does if it had been defined as public new void XYZ(Child c). But same is not the case with C++. It gives us no suprise.

And as far as C++/CLI is concerned, it behaves as traditional C++.

So the intriguing bitter part is that the overloading in the managed world is not a thing at the CLR level nor does it seem to be something concerned with the specification. It seems to be a matter of taste.

.NET Reflection Extravanganza !!!

Over the past few weeks, I have been involved with this module that got the best of both worlds – .NET and I, 😁.

Ok, this was the problem. We have a COM server, let us name it Server. I had to write an assembly in C#, let us call it Bridge, that will listen to all of the events fired by the Server and perform an action Action. To keep that Action simple, let us assume we have to log them to the database. But the Server fires hundreds of events, and it is not wise to write up static event handlers for all of them. Also, if more events are (ever) added in the future, the Bridge should be able to support it without code changes.

The twist in the game was that this was an brown + green field development project. That demanded a wise solution – learn from the past and better the future.

Continue reading .NET Reflection Extravanganza !!!