C# in Depth

Simple generics for everyday use65on the extra information (for instance, offering the members of string as next stepswhen you access an element of a list of strings); callers of methods can be more certainof correctness in terms of arguments passed in and values returned; and anyone maintainingyour code can better understand what was running through your head when youoriginally wrote it in the first place.NOTE Will generics reduce your bug count? Every description of generics I’ve read(including my own) emphasizes the importance of compile-time typechecking over execution-time type checking. I’ll let you in on a secret: Ican’t remember ever fixing a bug in released code that was directly dueto the lack of type checking. In other words, the casts we’ve been puttingin our C# 1 code have always worked in my experience. Those casts havebeen like warning signs, forcing us to think about the type safety explicitlyrather than it flowing naturally in the code we write. Although genericsmay not radically reduce the number of type safety bugs you encounter,the greater readability afforded can reduce the number of bugs acrossthe board. Code that is simple to understand is simple to get right.All of this would be enough to make generics worthwhile—but there are performanceimprovements too. First, as the compiler is able to perform more checking, that leavesless needing to be checked at execution time. Second, the JIT is able to treat value typesin a particularly clever way that manages to eliminate boxing and unboxing in many situations.In some cases, this can make a huge difference to performance in terms ofboth speed and memory consumption.Many of the benefits of generics may strike you as being remarkably similar to thebenefits of static languages over dynamic ones: better compile-time checking, moreinformation expressed directly in the code, more IDE support, better performance.The reason for this is fairly simple: when you’re using a general API (for example,ArrayList) that can’t differentiate between the different types, you effectively are in adynamic situation in terms of access to that API. The reverse isn’t generally true, by theway—there are plenty of benefits available from dynamic languages in many situations,but they rarely apply to the choice between generic/nongeneric APIs. When youcan reasonably use generics, the decision to do so is usually a no-brainer.So, those are the goodies awaiting us in C# 2—now it’s time to actually start usinggenerics.3.2 Simple generics for everyday useThe topic of generics has a lot of dark corners if you want to know everything about it.The C# 2 language specification goes into a great deal of detail in order to make surethat the behavior is specified in pretty much every conceivable case. However, wedon’t need to understand most of those corner cases in order to be productive. (Thesame is true in other areas, in fact. For example, you don’t need to know all the exactrules about definitely assigned variables—you just fix the code appropriately when thecompiler complains.)Licensed to Rhona Hadida