C# Tips

C# generics syntax is elegant

C# generics syntax is much better than the nearest contender C++. Consider the following generic declaration in C++
template <typename T> // can use <class T> as well

class GenClass

I always felt the need to use the typename keyword is without any purpose. Most developers kept using <class T>. The designers of C# showed that the usage of template is also not required. The short and sweet syntax in C# is

class MyClass<T>

Constraint syntax sucks

This does not mean that everything is as small and sweet in C#. The usage of the struct keyword to indicate value type constraint is one such example. Say for a generic type I want to put a restriction that the type parameter can only be a value-type. I have to do it as follows

class MyClass<T> where T: struct
MyClass<int> mc = new MyClass<int>();

This is very un-intuitive because even for integral types like Int I need to use struct as the constraint. 
Similar issue is with specifying constraints on multiple type parameters. Consider the following

class MyClass<T,U> where T: struct where U: class

Only if I break the constraint to two lines can you read it

class MyClass<T,U> where T: struct
where U: class

There should have been some delimiter in between consecutive where to make the whole thing more readable.

The rules regarding the order of constraints initially taxes your memory but you get used to it soon. If I need a constraint that the type has to be a reference type that must have a public parameterless constructor I need to do the following

class MyClass<T> where T: class, new()

Here the order is important as class has to be the first contraint and new() has to be the last.

Enumerting all values of an Enum

Sometimes you need to do something in code and you hit on a simple solution, and then you sit back and marvel on the design that lets you do that. Sometime back when writing my blog on the usage of console color I needed to write some code that got all the values for the Enum ConsoleColor and print text using those colors. I used the following code.

static void Main(string[] args)
ConsoleColor originalCol = Console.ForegroundColor;
foreach(ConsoleColor color in Enum.GetValues(typeof(ConsoleColor)))
Console.ForegroundColor = color;
Console.WriteLine("{0, -12} {1}", color, color.ToString("D"));
Console.ForegroundColor = originalCol;

All of this could be done so easily is because of the unified inheritance structure of .NET. All enums inherit from System.Enum and so a lot of functionality comes to you for free. You can use Enum.GetValues to do the work of getting all the values and use the base Enum types ToString overrides to give you correct string/value representations of the enum. Try doing this in C++ and the difference is evident.

The fact that I could do this so easily made me extremely happy. Programmers should be lazy and a language or framework that allows them to be lazy should be the platform of choice.


Generic methods, delegates and type inference in C#2.0.

I did not like var in C# 3.0 because I felt it reduces code readability. For the same reason I do not like using Type-Inference in C# 2.0 generics.

class MyClass
public void MyMethod<T>(T value) {
Console.WriteLine("{0} {1}", typeof(T).FullName,
class Program
static void Main(string[] args)
MyClass mc = new MyClass();
mc.MyMethod(5);       // Type inference
mc.MyMethod<int>(12); // Explicit type parameter

Even though the first one using type inference requires less typing (and I'm sure will go a long way in CTS erradication) I prefer the more verbose explicit type parameter.

However when applied to generic delegates, type inference becomes a bit different. Consider the following

class MyClass
public delegate void Foo<T>(T item);
private void Bar(int i)
Foo<int> foo = MyMethod; // MyMethod<int> is inferred
//Foo foo = MyMethod<int>;
public void MyMethod<T>(T value)

I was talking to a friend some-time back and when compared to generic methods, he had assumed that type inference for generic delegate would mean that the type parameter of the delegate will be inferred. However as we see from the example above that the type of the delegate needs to be explicitly given and from this the type of the generic method is inferred. I am kind of OK with this because at least the types are specified in the statement.

Mixins and C#

In one of my previous lives when I first heard about mixin and tried to look it up I hit into various conflicting definitions. The definition of Mixin I settled for is "MixIn programming is a style of software development where units of functionality are created in a class and then mixed in with other classes". In C++ two common ways of doing this is multiple-inheritance and parameterized Abstract Sub Class (yep not Abstract Base class). I'll not get into MI because the basic design of C# will never allow it. However C# may be expanded to include Mixin using generics.

Mixin in C++
The definition of mixin above is pretty general. Even though mixin is a class it is intended to be combined with other classes and not to be used standalone. Mixins can be defined using parameterized inheritance of Abstract Sub class as follows

template <typename Base>
class MyMixin : public Base
template <typename Base>
class AnotherMixin : public Base

MyMixin<AnotherMixin<string> > mm;

In the above code both MyMixin and AnotherMixin derive from the type parameter passed to it. They are Abstract Sub classes because their super classes are not pre-determined. It is possible to chain them to create a singly inherited hierarchy so that the combined class gets the public functionality of all the mixin classes in the chain. Lets take a look at a more concrete example.

#include <iostream>
#include <string>
#include <ctime>
using namespace std;

template <typename T>
class AgeProvider : public T
time_t createdOn;
AgeProvider() {
double age() {
time_t currTime;
return difftime(currTime, createdOn);
string CreatedOn () { return ctime(&createdOn); }

template <typename T>
class CountProvider : public T
static unsigned counter;
CountProvider() {
unsigned GetCount() {
return counter;
template<class T> unsigned CountProvider<T>::counter = 0;

typedef AgeProvider<CountProvider<string> > TrackedString;

int main(int argc, char* argv[])
AgeProvider<CountProvider<string> > tstr;
tstr.append("Abhinaba ");
cout << "Content : " << tstr << endl;
cout << "Created : " << tstr.CreatedOn();
cout << "Age : " << tstr.age() << endl ;
cout << "Count : " << tstr.GetCount() << endl;
return 0;

Here the first mixin class in AgeProvider which gives info on the age in seconds of an instance of the class as well as when the instance was created. The other mixin is CountProvider, which gives how many instances of a specific class, was ever made. Both of these classes have no use on their own. However when they are mixed together with a stand-alone class like string they provide the funtionality of counting and age to that class. Interestingly the whole of the above works without any multiple-inheritance and not imposing any restriction on the Mixin classes on what they inherit from or the inheritance order.

Mixins In C#

Some suggest that extension methods in the upcoming C# 3.0 are a kind of Mixins, because you can put in functionalities in these methods and arbitrarily tag it onto any class you want. In the C# 2.0 specification section 20.1.3 it is clearly called out that the base class of a generic class has to be a constructed class type so this rules out using the above approach to be used in C#. I am not too sure on why we choose to explicitly disallow abstract subclass. Since C# does not support multiple-inheritance, IMO it should have supported Mixin style coding.

C#: Fast string comparison optimization

Sometime back I had blogged about using reference comparison to speed up ordinal string comparisons. Essentially this means that if you know for sure that your string is interned and you want to do an ordinal string comparison you can use the following optimization

if (command == "START")

Console.WriteLine("Starting Build...");
else if (command == "STOP")
Console.WriteLine("Stopping Build...");

// Optimization
if (Object.ReferenceEquals(command,"START"))
Console.WriteLine("Starting Build...");
else if (Object.ReferenceEquals(command, "STOP"))
Console.WriteLine("Stopping Build...");

This works only if the string command is an interned string. If its not (e.g. its accepted from command lines or is constructed) you can intern it using something like string internedCmd = string.IsInterned(command) ?? string.Intern(command); and then use the interned version of the same string.

However an email to the internal CSharp alias made me look again. The email stated that the static method String.Equals(a,b) is more efficient than instance method String.Equals(a). I looked in into the code and it appears that for static Equals we already do the reference comparison first, while for instance Equals we jump right to string comparison.

// Static Equals called from overloaded operator ==public static bool Equals(string a, string b)

// Static Equals called from overloaded operator ==
public static bool Equals(string a, string b)
      if ((object)a == (object)b)
          return true;

      if ((a != null) && (b != null))
          return string.EqualsHelper(a, b);
      return false;

This might get fixed in future .NET version when both Equals will do the reference comparison first. However, the optimization I suggested does not hold because its already been done in the framework right now.
So currently in the following snippet the second version is faster than the first

 string a = ...;
string b = ...;

string.Equals(a, b); // faster

Command line tool syntax

Command line interface (CUI) designs for many of the tools found with VS or in Windows were to include a bunch of individual commands or exe with options or flags.

To get a directory listing: dir <options> as in dir c:\temp /w
To create a directory: md c:\temp\foo
To delete a directory: rd /s c:\temp\foo

So even though all the tasks pertain to directory or path handling , you need to know three command to do the task. This design is slowly changing to the format of command <action> [</options:attributes>]

For example if we change the above commands to this format with the common command called dir, we will be getting

To get a directory listing: DIR list c:\temp /w
To create a directory: DIR  make c:\temp\foo
To delete a directory: DIR rem c:\temp\foo /s

So effectively user learning is reduced. One can argue that he still needs to remember the names of the actions. But in the previous case he needs to remember rd, md, dir. Now he knows everything to do with path handling is to be done with DIR. So he can run DIR /? to get the list of actions and then do a DIR list /? to know the options for listing. The other advantage is namespace pollution in terms of the names of the executables also reduces.

This new format has also been adopted in the VS as in the source control tool. So to get the listing of all workspaces on MyServer you  run the command

h.exe workspaces /s:MyServer

To create a new workspace you run the command

h.exe workspace /new MySpace /s:abhinab-test

I guess going forward we will see more and more of the standard OS commands also taking up this format. A very common example is the NET command.

.NET API's are not always honest

First a quiz, assuming that all required priviledges is there what is the output of the following code. All the important bits are marked in bold

class Program
static void Main(string[] args)
string dirName = @"c:\a.";
Console.WriteLine("Created {0}", dirName);
Console.WriteLine( System.IO.Directory.Exists(dirName) ?
"Dir exist": "Dir doesn't exist");
catch (Exception ex)
Console.WriteLine("Failed to create directory {0}: {1}",
dirName, ex.Message);

The output is
Created c:\a.
Dir exist

The problem is if I go to C:\ I see a folder names a and not a. The dot at the end is conveniently dropped. What more interesting is that even though a. does not exist the Directory.Exists API returns true. Windows does not support files and folders with a dot at the end. If you use command window to create a file with a dot at the end then you simply get the file without the dot and no error is reported. .NET Directory API's exactly simulate this, but the question is do I want the simulation? I'd like to see API's being honest and report issues if it fails to do something. API's are used at a lot of places and the burden of checking should be done inside the API and not on code calling the API.

In VSTS we just got hit by a bug due to this. When you create a Build Type using the the Wizard, the user can enter names with a DOT at the end. We then create a folder with that name and check the whole thing into Team Foundation Source Control. The problem is what gets created is a and not a. So even though you wanted to create a Build Type named a.  you have one named a and all sorts of weird things happen after that. Though this is kind-of a corner situation but still I'd prefer a more honest API anyday.

The CLR Nullable DCR works!!!!!

CLR took a DCR (Design Change Request) some time back on how nullable types are implemented. I found from one of the internal DLs that the fix was already in the RTM bits.

I wrote a small piece of code which should work only with the DCR changes and kept it aside so once this DCR gets implemented I'd try it out. So each time I upgraded to a new build of VS/CLR I built/ran this code to see if it works. And it just did, with my todays upgrade to about 10 day old build in our lab. The new nullable type after becoming a  basic runtime intrinsic just rocks. I have put in comment all the failures that used to happen previously with the same piece of code.

// this code works only with the latest bits of
// Visual Studio 2005 (C#2.0) and will fail to
// compile/run with older Beta2 bits

static void Main(string[] args)
    int? val = 1;
    int? nullval = null;
    // this always worked
    if (nullval == null)
        Console.WriteLine("It worked");

    // this used to fail before and I think one of
    // the biggest issue with the previous implementation
    object nullobj = nullval;
    if(nullobj == null)
        Console.WriteLine("It worked");
    // previously required 
    // box = Nullable.ToObject<int>(val); argh!!!!
    object box = val;
    // If you do not need exceptional code
    // (that's code that throws exception)
    // you needed to do int? unbox = Nullable.FromObject<int>(box);
    int? unbox = (int?)box;
    if (unbox == val)
        Console.WriteLine("It worked again");
    int intval = (int)box;
    if (intval == val.Value)
        Console.WriteLine("attained Nullable Nirvana");
    int x = 10;
    object y = x;
    // Previously Exception!!! cast is not valid
    int? z = (int?)y;
    IComparable c = val;
    // Previously Exception!!! : object type cannot be
    // converted to target type
    if(c.CompareTo(box) == 0)
        Console.WriteLine("I have seen it all");
    // compilation failure
    IComparable<int> ic = val;
    if(ic.CompareTo((int)box) == 0)
        Console.WriteLine("Wow there is even more to see");

The output of the program is
It worked
It worked
It worked again
attained Nullable Nirvana
I have seen it all
Wow there is even more to see

Its not a good idea to use Console colors too much

With Whidbey (VS2005) managed Console based applications have got a boost with new additions to the System.Console namespace. You can now change the color, size, buffer-size, cursor-size, cursor-position, window-title directly from a managed application without PInvoke.

However, just because it can be done easily, doesn't mean that it should be used. If you are developing a console based game or something similar like a chat client you have the liberty to do this. Otherwise think twice (or thrice) before you play around with any of these settings. The reason is simple most people (like me) will get super annoyed if for some reason the console window suddenly jumps and resizes when I run a program.

If you think that doing some thing simpler like changing the text color (using Console.ForegroundColor) to draw attention is Ok, consider it carefully. It might just not work, could look horrible on some specific console setting or might convey the wrong meaning. I have listed below some common usage of changing these setting programmatically and why they might not work. Most programmers agree and understand that playing with console window size or buffer-size is not a good idea and do not use it so I have omitted them from here.

Changing text color using Console.ForegroundColor
Warning and Error Messages: Using different colors for output text, like yellow for warnings and red for error might be fine. You just need to ensure that you use the right set of colors as their meaning are deeply bound in the mind of the users. The following table typically works

  • Yellow: warning
  • Red: Error
  • Green: Pass, success messages
  • Cyan: Information

Do NOT use colors when its not absolutely required: Its best to avoid using colors when not absolutely required. In most cases it'll lead to trouble and rarely be of any benefit. See the following example where the prompt comes in yellow. Since this is a console based application it would have blocked until I entered the required inputs so drawing attention with yellow does not add any value. Since yellow is associated with warning, a first-time user might thing that something is wrong and he's required to rectify this by entering some server name.

Welcome to my tool
Server  : MyServer
Username: Abhinaba

Do NOT use a dark color for text: People do change the background color of the console. I use Teal and DarkBlue often, so ensure that you do not choose one of the darker colors for the text as it might coincide with the background color of the console window and your text will be invisible. I once came accross a tool which used blue for text entered by the user. I had launched that application on a blue-background console. Since I was using the application for the first time, I had a hard time figuring out what was going on, as I couldn't see what I was typing.

The safe colors are Gray, Green, Cyan, Red, Magenta, Yellow and White. However sometimes even these colors in combination with background colors cause eye-sore as in

Some error message!!
Do restore the original color: Even if you use any of the above colors remember to switch the color back to the original color. Use some thing like
public void ShowError(string message)
    ConsoleColor orgCol = Console.ForegroundColor;
    Console.ForegroundColor= ConsoleColor.Red;
    Console.ForegroundColor = orgCol; // restore color

his might look trivial, but can be a big source of annoyance. Like your application gets an exception, the exception-handler sets color to red, shows the error message and the application exits. Now whatever I type in that console window is in Red!!!

Using Console.BackgroundColor

Do NOT change the background color: Console.BackgroundColor = ... is bad.  The reason being that the color is changed only for subsequent text and it looks horrible as below

Text before color change
Text after I changed the background col to cyan

Even though very few people intentionally do this, it does creep into application. Sometime back in some error message code I saw this.

Console.BackgroundColor = ConsoleColor.Black;
Console.ForegroundColor = ConsoleColor.Red;

This went undetected in test, until someone opened it in a Teal window and this is what came up

Some error message!!

laying with cursor

CursorVisible: You might want to hide the cursor when showing some output using Console.CursorVisible = false. Just remember to revert it back to the same visibility state as it originally was.
CursorPosition: Jumping the cursor around in the screen is not a main-stream scenario and most console application don't use it. However, I have seen some tools like build-systems use this to show subsquent outputs in the same line. Consider the following code

int currPos = Console.CursorTop; // get the current pos 
for (int i = 0; i < 30; i++)
    Console.WriteLine("Counting {0}", i);
    Console.CursorTop = currPos; // Go back to the same line

This shows the counter in the same line. This might be required in your application. However, in some cases its over-done and you can simply live without it...

Most programmers are used to UI guidelines. Unfortunately most of these guidelines ingnore command line interface and are silent on them.