Gotcha Generic Overload Resolution When Called Generically

Both VB and C# have a feature of generic overload resolution that is fairly helpful and yet a source of gotchas. Lets say you have two methods with the same number of arguments. One method has arguments with generic types and the other does not. For Example:

Design Guidelines Provide Type Inference Friendly Create Function For Generic Objects

Really this guideline is a bit longer but putting it all in a blog title seemed a bit too much. The full guideline should read: “If a generic class constructor arguments contain types of all generic parameters, provide a static method named Create on a static class of the same class name as the generic class which takes the same arguments and calls the constructor.” Quite a mouth full.

Have An Icomparer T But Need An Icomparable T

Previously we discussed the opposite problem. This is a lesser but often more frustrating problem because there is no, AFAIK, built in solution for the BCL. However it’s problem that can be solved once and reused with a generic solution. IComparable has all of the methods necessary implement IComparer.

Gotcha Ccomptrbase T Assignment

Today what started out as a crash due to a pure virtual call turned into finding a gotcha in CComPtrBase. Essentially the code in question boiled down to the following. Can you spot the problem?

Binaryinsert Part2

Previously I discussed a potential missing API in List(Of T).BinaryInsert. One of the items I mentioned was it had better performance because it was O(Log N) vs Insert and Sort which is O(NLogN). Several users correctly pointed out this was incorrect and that Insert() had the additional overhead of an Array.Copy() which is O(N)ish. But most agreed O(N) + O(LogN) was better than O(NLogN).