Evil Code #007: Overloads

Time to do a bit of Evil Code again. Let’s look into following set of classes first.

public class BaseParameter { }
public class DerievedParameter :BaseParameter { }

public class BaseClass
{
   public void Foo(DerievedParameter param) => Console.WriteLine($"Inside {nameof(BaseClass)}");
}

public class DerievedClass : BaseClass
{
   public void Foo(BaseParameter param) => Console.WriteLine($"Inside {nameof(DerievedClass)}");
}

The client code looks like following.

var instance = new DerievedClass();
instance.Foo(new DerievedParameter());
instance.Foo(new BaseParameter());

What could be output of the above ? There might be tendency that the one might be inclined to think about an output that resembles following.

Inside BaseClass
Inside DerievedClass

But interestingly that is not quite right. The overload rules ensures that when there is a probable method in the most derieved compile type, the derieved method is chosen, even if there is a better choice in base class. The output of the code would be as following.

Inside DerievedClass
Inside DerievedClass

This is one of the reasons why overloading of base class methods are not recommended.

Let’s take a step further and introduce IEnumerable as method parameters. That’s when things get even more interesting.


public class BaseClass
{
  public void Foo(DerievedParameter param) => Console.WriteLine($"Inside {nameof(BaseClass)}");
  public void Bar(IEnumerable<DerievedParameter> paramList) => Console.WriteLine($"Inside {nameof(BaseClass)}");
}

public class DerievedClass : BaseClass
{
  public void Foo(BaseParameter param) => Console.WriteLine($"Inside {nameof(DerievedClass)}");
  public void Bar(IEnumerable<BaseParameter> paramList) => Console.WriteLine($"Inside {nameof(DerievedClass)}");
}
 instance.Bar(new List<DerievedParameter> { new DerievedParameter(), new DerievedParameter() });
instance.Bar(new List<BaseParameter> { new BaseParameter(), new BaseParameter() });

What could be the output of above ? As per our earlier knowledge, the output would be

Inside DerievedClass
Inside DerievedClass

Well, the actual answer is slightly more complicated. If you are running the code in a framework above 4.0, then you are bang on target. But, if the target framework is lesser, you are in for a surprise.

Inside BaseClass
Inside DerievedClass

The reason for the above scenario is that post 4.0, C# generic interfaces support covariance and contravariance, which wasn’t the case for frameworks prior to that. This results in above scenario.

Happy Coding

Advertisements

Evil Code #006 : Build Configurations

This one is courtesy Wouter de Kort, from his famous book. Okay, so what’s the evil code here. Consider the following code and predict the output in Debug as well as Release modes.

static int count = 10;
static void Main(string[] args)
{
  Timer timer = new Timer(CallBackMethod, null, 0, 2000);
  Console.ReadLine();
}

private static void CallBackMethod(object state)
{
  if (--count == 0)
  Environment.Exit(0);

  Console.Write(count);
  GC.Collect();
}

Output of the code under different configurations

// Debug Mode
987654321
// Release Mode
9

Isn’t that weird that the output has varied in Debug and Release modes ? Well, the key player in charge of this different output is the Garbage Collector and code optimization. When in the Release mode, the compiler optimizes the code realizing that timer object is not used again. This results in the CallBackMethod being executed only once.

Evil Code 0002 Optional Parameter Vs Method Overloading

Again one of those things which looks so simple, but could drive one mad during debugging.

Much before Optional Parameters came in, C# developers used to depend on Method Overloading for mimicking Optional Parameters. Consider a scenario where both exists, what would be the output ?

Image

The output would be :

Image

The reason behind this is the overload resolution method adopted when we have a overloaded method and a method with optional parameter. Here is what MSDN says.

If two candidates are judged to be equally good, preference goes to a candidate that does not have optional parameters for which arguments were omitted in the call. This is a consequence of a general preference in overload resolution for candidates that have fewer parameters.

Evil Code 0001 : Lambda and Ref/out

What would be output of following ?

        static void Main(string [] args)
        {
            List< int> numlist = new List< int>() {1,2, 3, 4, 5, 6, 7 };
            CalculateAndPrint( ref numlist);
        }
 
        public static void CalculateAndPrint( ref List< int> Num)
        {
            var n = Num.Where(d => d > Num[2]);
 
            foreach ( var item in n)
            {
                Console.WriteLine(item);
            }
        }

The most obvious answer is 4,5,6,7. However that’s not. This code refuses to compile because Lamba expressions  cannot accept variables that are declared in an outer scope.