People are free to ignore it, but considering you could easily copy/paste the code and change a few types it’s rather quick considering the number of times those people are going to keep casting their enums to ints (which is also throwing type safety out the window). If you type (int) about a dozen or so times, you’ve likely typed just about as much as that class; more if you just copy/paste it and change the type to the new enum. In that sense it’s almost more appropriate that lazy developers would implement this whenever using an enumeration for a dictionary key.

I guess the moral of the story for inexperienced C# and .NET coders learning XNA is to keep an eye out for all .NET data structures and classes whose implentation might be using that pesky System.Object as a default type and, where possible, provide your own specific type based on the needs of your program.

I’m slowly realising the generalised nature of System.Object can be great for making life somewhat easier for the more sedentary event-driven applications, or maybe even in areas of XNA code that are called once, but you sure as heck do not want one living in tight code loops such as Update and Draw that are called frequently

Thanks for taking the time to give some insight into this.

IEqualityComparer<T> lets you determine if two objects are equal. That’s really all the interface is for. A dictionary will provide a default IEqualityComparer<T> using the EqualityComparer<T>.Default property if you do not provide one on your own. The comparer that is generated first determines if T implements IEquatable and if so uses that to determine equality. If T does not implement IEquatable (as is the case for all enumerations) the EqualityComparer<T>.Default will have an implementation that relies on the object.Equals override available for the type, which for enumerations means they take in type object. Passing the enumeration as an object will cause boxing and thus create garbage.

Thus if you pass in your own implementation of IEqualityComparer<T> the dictionary will use that instead, so if we just give it a comparer that doesn’t rely on the object.Equals method, we avoid it using the default implementation and the garbage it creates.

However, I feel that many newcomers to XNA might also be fairly new to C# and .NET, so would it be possible when covering topics like this one to not only describe the immediate ’solution’, but also have a preliminary chat about the ‘Why’ you need to do it and some talk of ‘How’ it works?

I’m not familiar with the IEqualityComparer interface and the MSDN help files are less than enlightening to this newcomer, so it’s not entirely clear why your solution works without some background into the problem it’s solving. For example I thought in using Generics you avoid any boxing / unboxing gargage generation purely by virtue of using a Generic because it’s using a specific type rather than System.Object?

Keep up the great work, I for one hugely appreciate it.