the blog => anything goes : software C# language

Confusion++

Senthil — Thu, 26 Feb 2009 13:09:44 GMT

I'll bet a hundred bucks that any entry level C++ interview or exam will somehow drift into questions about the pre and post increment operators. It's almost become a canonical, rite of passage sort of thing.

Now using the operators is one thing, overloading them for your own types is another. In C++, you write something like

class X {
    int val;
public:

    X() : val(0){ }

    X operator++() { val++; return *this; }
    X operator++(int) { X pX = *this; val++; return pX; };

    int Value() { return val; }
};

Fairly straightforward stuff - C++ uses the int overload to distinguish between pre and post, and the post increment overload copies itself before incrementing and returns the copy.

Now let's see how to do this in C#.

class X
{
    public int Value { get; set; }

    public static X operator ++(X p)
    {
        int x = p.Value;
        return new X() { Value = x + 1 };
    }
}

No, there's no separate overload for the other one - the same method works for both pre and post increment operations. The compiler does the work of generating code that exhibits correct pre and post increment behavior. For code like

X x = new X();
X y = x++;

it generates

X x = new X();
X y = x;
x = X.op_Increment(x);

and for code like

X x = new X();
X y = ++x;

it generates

X x = new X();
X y = x = X.op_Increment(x);

Nifty, eh?

But wait, did you notice the difference between the C++ and C# overload implementation? The C# overload does not modify the original at all and always returns a copy, whereas the C++ code always modifies the current instance and returns a copy only for the post increment overload. Looking at the generated code, it should be easy to understand why - the compiler can't do its magic if the overload tinkers with the original instance.

Did you notice that X is a reference type?

X x = newX();
Xy = x;

x++;

Given that x and y are referring to the same object after executing the second line, shouldn't the increment be visible from y as well? It doesn't happen though, because the overload returns a new instance that then gets assigned to x, leaving y referring to the "old" unmodified instance.

All this confusion will not arise if X is a value type. The assignment of x to y will create a copy, so there's no possibility of changes in x reflecting in y. And modifying the passed instance from within the operator overload will have no effect on the original instance either.

Moral of the story : watch out when overloading operators on reference types.

One of those 'doh' moments

Senthil — Sun, 25 Jan 2009 20:22:00 GMT

There are times when you feel really proud of yourselves; on top of the world, with no one in sight. And then there are times when you can't believe you did what you just did. Here's one of the latter :-

My task was to show a progress bar in our application. Nothing fancy there - just division of the operations to be performed into equal size chunks and Incrementing after completion of each task. Very straightforward indeed.

	int increment;

        private void Form_Load(object sender, EventArgs e)
        {
            int discreteOperationsCount = GetDiscreteOperationsCount();
            increment = (int)Math.Ceil((double)progressBar.Maximum / discreteOperationsCount);
        }

        private void OperationCompleted()
        {
            progressBar.Increment(increment);
        }

It worked great when I tested it with 5, 10, 20 operations. I was even pleased that I cast the numerator to double straightaway, as I was typing code.

Only until I found that the progress bar progresses too fast if the number of operations is more than 100. If the result of the division is less than 1, Math.Ceil pushes it up to 1, which means that the progress bar will be full when 100 (the default Maximum value) operations complete, regardless of the actual number of operations.

Doh.

Ok, I thought, so let's store increment as a double and call Increment with that number. It would have worked, but for the fact that Increment does not have any overloads - it only accepts an integer. Hmm.. what gives?

After a little bit of thought, I figured out a way - scale everything by the degree of precision needed. With a scaling factor of 10, the calculation now becomes

increment = Math.Ceil((double)progressBar.Maximum / discreteOperationsCount * 10);

If discreteOperationsCount is 520, for example, then increment would become (100 * 10) / 520 * 10 = 19. We still have an integer, but it is more precise than the one calculated earlier.

Of course, you could increase the scaling factor further, and the number of significant digits will also increase exponentially. But the progress bar will have to do some approximation when mapping progress to pixels on the screen, so beyond a point, the increase in precision doesn't pay off that much.

Like I said at the top of this post, I couldn't believe I missed testing with the number of operations greater than the progress bar's Maximum. Truly one of those 'doh' moments.

The dangers of Thread.Abort

Senthil — Wed, 17 Dec 2008 18:09:00 GMT

There have been a lot of blog posts about why calling Thread.Abort from one thread to abort another is a bad idea. If you're still wondering if it actually is that bad, you'll be convinced by the end of this blog post :).

The other day, I was investigating frequent hangs in our application on the production machine. The only clue was that the last logged exception was a ThreadAbortException. What made it interesting was that in some cases, the application continued to run fine after logging the exception. As I continued to look at the log data, I realized that every time the application hung, the ThreadAbortException's stack trace had a particular third party library's method at the top of the stack. The conclusion was that the application hanged whenever the thread was aborted when executing the third party library's code.

Reflector and half an hour later, the reason for hanging became clear. The third party code looked like this :-

void DoX()
{
    Monitor.Enter(lockObj);
    //Do some interesting stuff
    Monitor.Exit(lockObj);
}

Now do you see why? If the ThreadAbortException gets thrown after acquiring the lock but before releasing it, the lock gets orphaned and no other thread will be able to acquire it. Ever. The third party library is used heavily by our app, so any thread that calls DoX after the abort will hang forever.

OK, so let's set it right then.

void DoX()
{
    lock(lockObj)
    {
        //Do some interesting stuff
    }
}

The compiler will emit a try/finally block and will call Monitor.Exit from the finally block. That should solve the problem, right?

Maybe.

The CLR guarantees that it won't throw ThreadAbortExceptions when running finally blocks (and CERs and constructors), so once the finally block starts executing, we're safe. But what about if there is (JIT compiler generated) code that is run after the try block but before the finally block?

Even assuming there is no such code, things can still fail.

void DoY()
{
    using (StreamReader sr = new StreamReader("Test.txt"))
    {}
}

If a ThreadAbortException is thrown after the StreamReader constructor runs, but before the constructed instance gets assigned to the local variable (sr), then sr won't be disposed.

The bottom line is that it is really hard to write code that works properly in the face of ThreadAbortExceptions. And even if you somehow manage to write it, you can never be sure that all your external libraries are written to cope with it.

Moral of the story : Listen to all the good advice and don't call Thread.Abort from another thread :)

Not all IEnumerable are equal

Senthil — Thu, 04 Sep 2008 19:25:00 GMT

Implementing IEnumerable<T> can turn out to be tricky in certain cases. Consider the following code snippet

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Consume(new List<string>() { "a", "b", "c" });
        }

        static void Consume<T>(IEnumerable<T> stream)
        {
            T t1 = stream.First();
            T t2 = stream.First();

            Console.WriteLine(t1.Equals(t2));
        }
    }
}

As you'd expect, it prints true. Each First() call results in a call to stream.GetEnumerator(), and each such enumerator returns elements from the beginning of the list, so calling First() twice returns the same (first) element. All good so far.

Here's a tiny class.

        class StringGenerator
        {
            int index;

            public string GetNext()
            {
                return (index++).ToString();
            }
        }

As you can see, it generates whole numbers as strings. Not very convenient to use though, wouldn't it be great if we can wrap it and make it enumerable?

        static IEnumerable<string> ConvertToEnumerable(StringGenerator g)
        {
            string item = null;

            while ((item = g.GetNext()) != null)
                yield return item;
        }

ConvertToEnumerable simply loops over the list of items generated and makes use of yield return to make it enumerable.

Great, now what does

        Consume(ConvertToEnumerable(new StringGenerator()));

print?

It prints false.

False? FALSE? Can you figure out the reason?

If you've read Raymond's posts on implementation of iterators, you should have figured it out by now. The crux of the problem is that all enumerators returned share the same instance of StringGenerator. Calling First() twice results in two calls to GetNext() on the same StringGenerator instance, and the values returned will obviously be different. To verify that, try creating the StringGenerator instance inside the ConvertToEnumerable function - it will print true now.

This bit me when I wrote code that parsed stuff out of an IEnumerable<string> instance. The actual program read text from a file, so I had a ConvertToEnumerable routine just like the one above, except that it took TextReader as the parameter. The Consume method passed the constructed IEnumerable<T> instance to various methods (say Method1 and Method2), with the assumption that whatever Method1 read off the stream won't be read again by Method2.

As we saw just now, this works if Consume is passed an IEnumerable<T> constructed like the StringGenerator case. It fails badly if a List<string> is passed instead. Because I wanted the "read elements off the stream" behavior, I called GetEnumerator() once for the passed IEnumerable<T> and then changed the methods called by Consume to take that IEnumerator<T> instead of IEnumerable<T>. That made the code work correctly for both cases.

Moral : Make sure you understand the implications when yield returning items off a shared item source.

String.Empty versus "" - The real deal

Senthil — Fri, 27 Jun 2008 13:36:00 GMT

This is one topic that keeps popping up every now and then. A lot of people seem to be curious about the performance implications of using one versus the other, and not unexpectedly, a lot of different answers come up.

To settle it once for all, here's a small program that uses both of them.

namespace ConsoleApplication
{  
    class Program
    {
        static void Main()
        {
            Method1();
            Method2();
            Console.ReadLine();
            Method1();
            Method2();
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static void Method1()
        {
            string s = "";
            DoNothing(s); 
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static void Method2()
        {
            string s = string.Empty;
            DoNothing(s);
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static void DoNothing(string s)
        {
            Console.WriteLine(s);
        }
    }
}

As you can see above, Method1 and Method2 call DoNothing, passing "" and string.Empty respectively. Now how do we compare these two? Easy, just look at the jitted code - after all, that's what is going to run on the machine.

We'll use Windbg to disassemble the code after the JITter did its job. And if you're wondering why Method1 and Method2 have been called twice, now you know why - the second time around, we can look at the JITted code that was generated as part of the first time execution of each of those methods.

So breaking into the debugger at Console.ReadLine() and dumping the method descriptors for Program

0:003> !Name2EE Sample.exe!ConsoleApplication.Program
...
MethodTable: 002a3048

0:003> !DumpMT -MD 002a3048
...
--------------------------------------
   Entry MethodDesc      JIT Name
...
00860070   002a3020      JIT ConsoleApplication.Program.Main()
008600a8   002a3028      JIT ConsoleApplication.Program.Method1()
00860100   002a3030      JIT ConsoleApplication.Program.Method2()
008600c8   002a3038      JIT ConsoleApplication.Program.DoNothing(System.String)
002ac021   002a3040     NONE ConsoleApplication.Program..ctor()

shows the method descriptors for all the methods in that class. Now, using !u to disassemble code for Method1

0:003> !u 002a3028
Normal JIT generated code
ConsoleApplication.Program.Method1()
Begin 008600a8, size d
008600a8 8b0d3c30e402    mov     ecx,dword ptr ds:[2E4303Ch] ("")
008600ae ff158c302a00    call    dword ptr ds:[2A308Ch] (ConsoleApplication.Program.DoNothing(System.String), mdToken: 06000004)
008600b4 c3              ret

and then for Method2

0:003> !u 002a3030
Normal JIT generated code
ConsoleApplication.Program.Method2()
Begin 00860100, size c
00860100 8b0d2c10e402    mov     ecx,dword ptr ds:[2E4102Ch] ("")
00860106 e8bdffffff      call    008600c8 (ConsoleApplication.Program.DoNothing(System.String), mdToken: 06000004)
0086010b c3              ret

shows that, surprise surprise, the generated assembly code is identical. The only difference is the address referenced in the mov instruction.

So there you have it - the JITter generates the same code whether you use String.Empty or "", and there should no difference in performance.

PS : It's interesting to note that the two addresses are different, even though the string contents are the same. Address 2E4303Ch in the disassembly for Method1 is the address referring to an interned string object with the content "". You can verify that by creating another string variable initialized to "" and disassembling that code - the same address (2E4303Ch) will be referenced there as well. What's surprising is that the address referenced in Method2 is different - which means the string object referenced by string.Empty is not the interned object. Wonder why - maybe because it's ngen'ned code?

Itertools for C# - Tee

Senthil — Mon, 05 May 2008 17:03:00 GMT

Tee is a cool function that "clones" enumerators whatever their current state is - it basically allows you to branch off an enumerator into as many enumerators as you want, all independent of each other.

You can do something like

List<int> list = new List<int> { 1, 2, 3, 4, 5 };

IEnumerator<int> iterable1 = list.GetEnumerator();

IEnumerator<int> []teedIterables = Itertools.Tee(iterable1, 2);

foreach(int val in teedIterables[0])
{
   Console.WriteLine(val);
}

foreach(int val in teedIterables[1])
{
   Console.WriteLine(val);
}

// prints 1 2 3 4 5 1 2 3 4 5

If there was a iterable1.MoveNext() before the call to Tee, then the output would have been 2 3 4 5 2 3 4 5. The implementation proved to be pretty interesting - and complicated, partly because the C# compiler does not allow the yield statement inside anonymous methods. Here's the implementation.

public static IEnumerator<T>[] Tee<T>(IEnumerator<T> source, int count)
{
    List<T> tValues = new List<T>();
    IEnumerator<T>[] results = new IEnumerator<T>[count];

    for (int i = 0; i < count; ++i)
    {
       int currentLocation = 0;
       results [ i ] = CreateEnumerator(source, new EnumeratorState<T>() { CurrentLocation = currentLocation, TValues = tValues });
    }

    return results;
}

private static IEnumerator<T> CreateEnumerator<T>(IEnumerator<T> source, EnumeratorState<T> state)
{
   while (true)
   {
      if (state.CurrentLocation < state.TValues.Count)
      {
          yield return state.TValues[state.CurrentLocation++];
      }
      else
      {
         if (source.MoveNext())
         {
            state.TValues.Add(source.Current);
            state.CurrentLocation = state.TValues.Count;
            yield return source.Current;
         }
         else
         {
             break;
         }
      }
   }
}

class EnumeratorState<T>
{
   internal int CurrentLocation { get; set; }
   internal List<T> TValues { get; set; }
}

There's a fair bit of code involved, as you can see. The basic idea behind the implementation is to maintain a list as a backing store. Each teed off enumerator attempts to read from the list - if it hits the end of the list, it advances the original enumerator and gets the current value, updates the list and returns that value. The rest of the code is plumbing to work around the inability to use yield inside an anonymous method. The code basically does what the compiler would have done - there's the EnumeratorState class to hold captured variables and a new instance of the class is created and passed to CreateEnumerator, which is in the place of the anonymous method.

Tee is that kind of function that is incredibly useful once you know you can do such a thing. Let's say you have an application that needs to process lines in a file, but the processing can happen in different contexts, independent of each other. Take for example, a log parser, that goes through each line in a file, looking for the start of an operation. The log parser notifies another component once it finds the start of the operation and proceeds through the file looking for the next operation. Normally, you'll solve the problem by adding the component to a list that gets notified after the parser reads each line. With Tee, you can simply tee off an enumerator and pass it to the other component - both the log parser and the component now have independent enumerators and can actually run in parallel. And you can tee off as many enumerators as there are components.

With that, we come to the end of this series of blog posts on implementing itertools in C#. The source code for all the functions implemented in the series is available at http://code.msdn.microsoft.com/itertools.

Not just a function : Generating functions

Senthil — Tue, 12 Feb 2008 15:29:00 GMT

Every now and then, you hit some problem that a programming language helps solve very cleanly. Here's the problem.

You are writing a series of functions that return a bool depending on some condition (predicates). Something like

bool Foo(State t);

Let's also assume that State is defined as

class State  { Color c; ... }

You have a set of colors, known at compile time, for which Foo should return true. How would you go about doing it?

You could pack the set of colors into an array and write Foo so that at runtime, it searches the color array and returns true if the color passed is in the array. Something like

bool Foo(State t) { return colors.IndexOf(t.Color) != -1; }

Assume that, for design reasons, it isn't really possible to allow access to colors from within Foo. Then what?

Anonymous methods and closures, of course. How about writing a function, that returns a Foo that returns true only if the color matches. Whew, that sounds confusing, but the code looks pretty simple.

Foo GenerateFoo(Color color) { return delegate(Color passedColor) { return color == passedColor; } }

You can then call GenerateFoo(Color.Red) to get a Foo that will return true only if it is called with Color.Red, call GenerateFoo(Color.Orange) to get one that returns true only if called with Color.Orange and so on.

Foo redFoo = GenerateFoo(Color.Red);
Foo orangeFoo = GenerateFoo(Color.Orange);
Console.WriteLine(redFoo(Color.Red)); // prints true
Console.WriteLine(redFoo(Color.Yellow)); // prints false

Nifty, eh?

C# 3.0 compiler bug - Using object initializers, generics and value types

Senthil — Wed, 26 Dec 2007 17:44:00 GMT

There is a description of the bug here. The following piece of code demonstrates the bug.

    class Program
    {
        interface I
        {
            int X { get; set; }
        }

        struct S : I
        {
            public int X { get; set; }
        }

        static void Main(string[] args)
        {
            Func<S>();
        }

        static void Func<T>() where T : I, new()
        {
            var c = new T() { X = 1 };
            Console.WriteLine(c.X);
        }
    }

The code prints 0 instead of 1. The bug goes away if object initializers are not used - changing var c = new T() { X = 1 }; to var c = new T(); c.X = 1; will print 1.

I had assumed all along that object initializers were transformed into property setters at the source code level (or somewhere above IL). This bug doesn't help much to confirm that :)

Anyway, let's see what's causing the problem. Peeking into the generated IL,

   .locals init (
        [0] !!T c,
        [1] !!T <>g__initLocal0,
        [2] !!T CS$0$0000)
        ... // Store zeroed out instance of S in locals[1]
    L_0022: ldloc.1 
    L_0023: box !!T
    L_0028: ldc.i4.1 
    L_0029: callvirt instance void CSharp3Test.Program/I::set_X(int32)
    L_002e: nop 
    L_002f: ldloc.1 
    L_0030: stloc.0 
    L_0031: ldloca.s c
    L_0033: constrained !!T
    L_0039: callvirt instance int32 CSharp3Test.Program/I::get_X()
    L_003e: call void [mscorlib]System.Console::WriteLine(int32)

Can you spot the problem now?

You can see that at L_0023, S is boxed and the boxed instance is used to make the virtual call to set X. You can also see that the boxed instance is not stored in any of the local variables, the callvirt instruction pops it off the stack and then it's gone. To load the value of X, the callvirt instruction is given a reference to c (locals[0]), which contains the unboxed instance of the struct. Which is why we are getting a 0 (the default value), instead of 1. Essentially, the compiler is generating the equivalent IL for something like

   S s = new S();
   I i = s;
   i.X = 10;
   Console.WriteLine(s.X);

This again prints 0 instead of 10, because i is assigned a different (boxed) instance of S and therefore changing i.X doesn't change s.X.

But then how does doing the initialization in two steps (var c = new T(); c.X = 1) work. The answer - Two step initialization does not use boxing when setting the value of X. Here's how the generated IL looks.

   .locals init (
        [0] !!T c,
        [1] !!T CS$0$0000)
    L_0021: stloc.0 
    L_0022: ldloca.s c
    L_0024: ldc.i4.1 
    L_0025: constrained !!T
    L_002b: callvirt instance void CSharp3Test.Program/I::set_X(int32)
    L_0030: nop 
    L_0031: ldloca.s c
    L_0033: constrained !!T
    L_0039: callvirt instance int32 CSharp3Test.Program/I::get_X()
    L_003e: call void [mscorlib]System.Console::WriteLine(int32)

The box instruction is gone, instead, the compiler has generated a constrained prefix for the callvirt instruction. MSDN says that

"When a callvirt method instruction has been prefixed by constrained thisType, the instruction is executed as follows:

If thisType is a reference type (as opposed to a value type) then ptr is dereferenced and passed as the 'this' pointer to the callvirt of method.
If thisType is a value type and thisType implements method then ptr is passed unmodified as the 'this' pointer to a call method instruction, for the implementation of method by thisType.
...

In other words, the address of the instance is passed as the this parameter to the call method - no boxing at all. If you'd looked carefully enough, the getter for X uses the constrained prefix, even in our buggy IL (the first listing).

That explains the bug then, but opens up another question. If virtual dispatch can be done for a value type without boxing, then why not do it that way for

   S s = new S();
   I i = s;
   i.X = 10;

as well? Mind you, virtual dispatch doesn't mean anything for value types, as they cannot derive from or derived by anything else, so any callvirt instruction on value types can be treated as a straight call instruction. The constrained prefix does exactly this, after making sure that this is a value type. So why not use it for all virtual calls? Performance (not many value types implementing interfaces)?

What do you think?

Mucking around with instance field initializers - Part 2

Senthil — Sun, 23 Dec 2007 18:20:00 GMT

We saw in Part 1 that C# doesn't allow an instance field initializer to refer another field in the class. Before trying to figure out why, let's first see if this is a restriction imposed by C#, rather than by the CLR.

Some disassembling and reassembling later, this is what the new IL code looks like.

    IL_0000:  ldarg.0
    IL_0001:  ldc.i4.1
    IL_0002:  stfld      int32 ConsoleApplication1.Program::x
    IL_0007:  ldarg.0
    IL_0008:  ldarg.0
    IL_000b:  ldfld      int32 ConsoleApplication1.Program::x
    IL_0009:  ldc.i4.1
    IL_000a:  add
    IL_000c:  stfld      int32 ConsoleApplication1.Program::y
    IL_000d:  ldarg.0
    IL_000e:  ldfld      int32 ConsoleApplication1.Program::y
    IL_000f:  call       void [mscorlib]System.Console::WriteLine(int32)

It's basically the same code in Part 1, except for the initialization of y. Instead of initializing y to 2, the code tries to load this.x, add 1 to it, store the result in y (y = x + 1) and then print out the result. The call to the constructor of System.Object comes next, but I've left that out for clarity.

Guess what, it works! The code assembles, checks out with peverify and runs fine, printing the value 2.

So, it looks like the CLR does not have any problems accessing other instance fields when initializing them. Then why doesn't the C# compiler like them?

How about fields inherited from a base class? If C# doesn't have the instance field initializer restriction, then the following piece of code should compile . What do you expect the value of y to be?

    class A
    {
        protected int x = 1;
    }

    class B : A
    {
        int y = x + 1;
        B() { Console.WriteLine(y); }
    }

1? 2? It depends on where the C# compiler puts the instance field initialization code. According to the current spec, it's placed before the call to the base class constructor, which means that y will be initialized to 1. Suddenly, the derived class now gets to access uninitialized base class state. Not good at all.

You could argue that the compiler knows about inherited fields and therefore can apply the restriction only to those fields - but that would add a nasty special case to the "you-cannot-reference-during-instance-field-initialization" list. I don't think it will be intuitive either - a typical programmer will be surprised if a "Move to base class" refactor suddenly breaks working code.

Static fields don't have this problem - they aren't really "inherited". Which could be why the compiler allows static field initializers to reference other fields.

What do you think?

Mucking around with instance field initializers - Part 1

Senthil — Thu, 06 Dec 2007 13:02:00 GMT

What do you think of the following piece of code?

    class Program
    {
        int x = 1;
        int y = x + 1;
    }

Looks simple, except that it doesn't compile (error CS0236: A field initializer cannot reference the non-static field, method, or property 'Program.x')

Try making x and y static - the code will compile fine now. I have been trying to find out why - so far, I haven't got a clue. Just in case it's not obvious, I do know that moving y = x + 1 into the body of Program's constructor will get me what I want, but I was (and am) curious to know why field initializers, and only instance field initializers, aren't allowed to access non-static fields.

The C# spec says that field initializers "correspond to a sequence of assignments that are executed immediately upon entry to any one of the instance constructors", just before the call to the base class constructor. When I generated IL for Program's constructor after replacing y = x + 1 with y = 2, it looked like this

    L_0000: ldarg.0 
    L_0001: ldc.i4.1 
    L_0002: stfld int32 ConsoleApplication1.Program::x
    L_0007: ldarg.0 
    L_0008: ldc.i4.2 
    L_0009: stfld int32 ConsoleApplication1.Program::y
    L_000e: ldarg.0 
    L_000f: call instance void [mscorlib]System.Object::.ctor()
    L_0014: nop 
    L_0015: ret

The generated IL matches with the spec - 1 and 2 are stfld'ed into x and y before calling the base class constructor (System.Object::.ctor()).

The C# spec also says that a field initializer is not allowed to reference the this pointer - " variable initializer for an instance field cannot reference the instance being created." It doesn't say why though.

The IL shown above clearly indicates that this (ldarg.0) is valid when storing 1 and 2 into x and y. So why doesn't C# allow y = x + 1?

I initially wondered if that rule is to prevent code like this

    class Program
    {
        int x = y + 1;
        int y = x + 1;
    }

but then, the C# spec clearly says that the variable initializers will be run in "textual" order. If you combine that with the fact that x and y will be assigned their default values even before their variable initializers run, you'll see that the above code should run fine, resulting in x = 1 (because y is zero) and y = 2. You can make x and y static and run the code, you will see the same result.

So again, why? Can you figure out why? We'll do some more digging into this in the next post.

Type inference != Dynamic typing

Senthil — Mon, 19 Nov 2007 16:27:00 GMT

Local variable type inferencing is a new feature in C# 3.5 - a very "handy" one, in that it saves a lot of typing. Basically, it lets you do

var dict = new Dictionary<string, List<int, Dictionary<int, string>>>();

instead of

Dictionary<string, List<int, Dictionary<int, string>>> dict = Dictionary<string, List<int, Dictionary<int, string>>>();

That's pretty cool, but remember, C# is still a statically typed language. dict is statically bound to the type Dictionary<string, List<int, Dictionary<int, string>>> and you cannot change it. You cannot do

dict = Dictionary<int, string>();

in the same method. The compiler will complain that the type on the RHS is not convertible to the statically bound type of dict.

Contrast this to a dynamically typed language like Javascript, which also uses the var keyword to declare variables.

var x = 1;x = new Array();
x = "23";

Or to Python

x = 42x = def fn(z) : return z + 1

In such languages, variables (x, in our example) simply act as placeholders and get bound to the type of the value they are holding at the moment. In the first example, x is holding an integer after executing the first line. After executing the second line, it's holding an array. If the same two lines of code were to be written in a statically typed language, the second line would be correct only if an array is somehow convertible to an int.

The point of the post - don't be misled by the var keyword. The variable it declares is still a good old statically typed variable.

Mixing generics and polymorphism

Senthil — Sun, 14 Oct 2007 16:29:00 GMT

Polymorphism, which attempts to hide differences in implementation, and generics, which attemtps to highlight them by providing exact information about types, don't seem to mix very well. Consider the following fairly common pattern.

        class Base
        {
        }

        class Derived : Base
        {
        }

        abstract class Manipulator
        {
            List<Base> list;

            public Manipulator(List<Base> list)
            {
                this.list = list;
            }
         }

        class BaseManipulator : Manipulator
        {
            public BaseManipulator(List<Base> list)
                : base(list)
            { }
        }

        class DerivedManipulator : Manipulator
        {
            public DerivedManipulator(List<Derived> list)
                : base(list)
            { }
        }

        public static void Main()
        {
            List<Derived> list = new List<Derived>();
            list.Add(new Derived());
            DerivedManipulator d = new DerivedManipulator(list);
        }

The code above will not compile - the compiler complains that List<Derived> cannot be converted to List<Base> in DerivedManipulator's constructor. Which seems kindof strange, given that Derived[] is implicitly convertible to Base[]. But what would happen if implicit conversion occurred with generics?

List<Derived> derivedList = new List<Derived>();
List<Base> baseList = derivedList;
baseList.Add(new Base());
Derived d = derivedList[0]; // BOOM

All hell will break loose. The type safety that generics offer will disappear, obviating the very need for generics.

What can be done then? We could make Manipulator a generic class, taking the type of the List as a generic parameter and make DerivedManipulator derive from Manipulator<Derived>. But then we are only shifting the problem - treating Manipulators polymorphically becomes impossible then.

There seems to be a basic impedance mismatch between polymorphism and generics. Does anyone know of a better way to solve the problem?

The quirky ?:

Senthil — Sat, 19 May 2007 18:03:00 GMT

If there was ever a poll conducted for the most favorite C# operator, I'd guess the conditional operator ?:, also known as the ternary operator, will win hands down. I find it to be one of those tools that make things shorter and clearer at the same time. But how well do you know the operator?

What do you think is wrong with the following piece of code?

    interface IDoer {}

    class ADoer : IDoer { }
    class BDoer : IDoer { }
    class Program
    {
        static void Main(string[] args)
        {
            bool flag = bool.Parse(args[0]);
            IDoer doer = flag ? new ADoer() : new BDoer();
        }
    }

Looks straightforward, doesn't it? Yet, this does not compile; the error being

error CS0173: Type of conditional expression cannot be determined because there is no implicit conversion between 'ADoer' and 'BDoer'

The C# spec says that the two expressions that appear on either side of the : must be one of the following

Both of them should be of the same type
The first one should be convertible to the second
The second one should be convertible to the first

In the above case, ADoer and BDoer are both convertible to IDoer (because they implement IDoer), but because neither of them is implicitly convertible to the other, compilation fails. It doesn't matter to the compiler that the result of the expression is always convertible to IDoer, all it cares about is the deduction of the type of the ternary expression.

I guess this is one of those places where static typing gets in the way of the developer, instead of helping him. You win some, you lose some :)