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 … Continue reading Confusion++

One of those ‘doh’ moments

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() … Continue reading One of those ‘doh’ moments

The dangers of Thread.Abort

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 … Continue reading The dangers of Thread.Abort

Not all IEnumerable<T> are equal

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; … Continue reading Not all IEnumerable<T> are equal

String.Empty versus "" – The real deal

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); } … Continue reading String.Empty versus "" – The real deal

Itertools for C# – Tee

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 … Continue reading Itertools for C# – Tee

Not just a function : Generating functions

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 … Continue reading Not just a function : Generating functions

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

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 }; … Continue reading C# 3.0 compiler bug – Using object initializers, generics and value types

Mucking around with instance field initializers – Part 2

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 … Continue reading Mucking around with instance field initializers – Part 2

Mucking around with instance field initializers – Part 1

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 … Continue reading Mucking around with instance field initializers – Part 1