Last week a bunch of us went on a .NET “advanced” debugging course. Well, suffice to say, the course was not what we were really expecting and ended up being a course on how to read MS .dump files, step through (assembler) code with WinDbg and generally get to know the IL code from a .NET assembly (see my Microsoft Lied blog earlier on the raw facts of how VB.NET and C# are not the same).

Anyways, one of the people who works on the QA team for C#, Min Kwan Park, has an excellent blog on .NET debugging and walks you though some ideas around what to do, what not to do, and how to deal with some funny .NET problems (like debugging web services from a web service client and what to do when remote debugging hangs). There are also some great links to other debugging docs so if you want to really get some advanced debugging tips check out the blog here.

Today I got into a bit of a language pickle. I was writing some code for someone to show them how to write Unit tests (using NUnit of course). When you write lots of little snippets of code for people day in and day out, you usually end up writing it in a language that the end developer is most comfortable with. This usually means flipping back and forth between VB, VB.NET, C#, C++, and so on. So I was writing up a test and went to implement the code for the test by writing this in C#:

public void TheMethod(string name, int rate=30)



This was the typical language guffah that we keep making. Whether it’s adding a semi-colon at the end of a line of VB/VB.NET code or putting in Dim statements in C# code it’s embarassing. In this case, I forgot why C# couldn’t handle default parameters. In C++ (and some other OO languages) the above code could be called like this:

TheObject.TheMethod(“NYSX”, 10);

or this:


The second example would set the rate to 30 automagically. C# doesn’t have this feature (it’s the first time I tried it in C# today, silly me). I did some digging and found out one reason why C# doesn’t have this feature. It’s related to a specific implementation of the feature.

In the C++ world, when the user writes:


the compiler generates

TheObject.TheMethod(“NYSX”, 30);

In other words, the compiler takes the default value that is specified in the method prototype and puts it into the method call – it’s just as if the user wrote ’30’ as the second parameter. There’s no way to change that default value without forcing the user of the class to recompile, which is unfortunate. The overloading model works better in this respect. The framework author just defines two separate methods, and the single-parameter one calls the two-parameter method. This keeps the default value in the framework, where it can be modified if necessary.

It would be possible for a compiler to take something like the C++ definition and produce the overloads, but there are a few issues with that approach.

The first one is that the correlation between the code that the user writes and the code the compiler generates is less obvious. Microsoft generally tries to limit magic when possible, as it makes it harder for programmers. The second issue has to do with things like XML doc comments and intellisense. The compiler would have to have special rules for how it generates doc comments for the overloaded methods, and intellisense would need to have smarts to collapse the overloaded methods into a single method.

Writing overloads yourself is a bit less convenient, but Microsoft thinks it’s an acceptable solution. Guess I’ll just have to get in the habit of being embarassed when I write code (or write more of it in a single language rather than bunny hopping all over the language garden).