February 28, 2021
Hot Topics:

Comparing .NET Generics and C++ Templates

  • By Brent Rector
  • Send Email »
  • More Articles »

Here's what happens. The compiler sees a call to the CompareTo method on parameter arg1. The parameter arg1 is of type T and type T is known to be a type that implements IComparable. Therefore, the type of the object to which arg1 refers will have an instance method called CompareTo reachable via the type's IComparable implementation. So, the compiler generates a call to the interface method. With the constraint, the compiler has enough information to compile the generic method definition into type safe code prior to encountering any specializations of the method. Of course, subsequently, if you try and specialize this method using a type that does not implement IComparable, you will receive a compiler error because the type used during the specialization doesn't satisfy the constraint.

I need to point out that there are subtleties lurking in this approach. As mentioned above, when using generics, this code calls the IComparable::CompareTo method body. However, in .NET, one can explicitly implement an interface method on a class. In effect, this make the method "invisible" on the class itself and only reachable via the interface. Therefore, you can additionally implement a method with the same name and signature on the class itself. Here's an example:

class Foo : IComparable {
   int IComparable.CompareTo (System.Object o) {
   public int CompareTo (System.Object o) { ... }

Foo f1 = ...
Foo f2 = ...
Foo lessor = Min<Foo> (f1, f2);

The template equivalent of the above would call the public CompareTo method on the class, not the private explicit implementation of the interface's method.

There are other differences between C++ templates and .NET generics as well.

  • Templates support partial specialization; generics don't.
  • Templates allow you to write explicit specializations of a type (typically for more efficiency); generics permit you to provide a single generic definition that will be used at runtime for all specializations.
  • Templates allow the replaceable parameters to be any value; generics require the replaceable parameters to be replaced by type names.
  • Templates are a C++ only language feature; generics can be supported by any .NET language that wishes to do so.
  • A constraint specification is limited to a base class or a list of interfaces. This fundamentally means that code in a generic method body can primarily call interface methods on a parameterized type. Unfortunately, this also means that you cannot call static methods of the type argument's class, which eliminates many potentially useful methods such as its static conversion operators or static operators.

I'm sure the C++ template fans will continue to advocate template use. I expect VB.NET and C# developers to use generics heavily. Heck, if you're using a collection class containing value types in the Whidbey release, it makes no sense not to use the generic collection classes. However, with the new language features in the Whidbey version of C++ with Managed Extensions you can have your cake and eat it too (use templates and generics in the same code).

In fact, I may have to retreat from my stance of preferring C# and disliking MC++. With Whidbey, MC++ is a whole new language and nearly all of my current objections to it have disappeared. But, that's yet another article.

About the Author

Brent Rector has designed and written operating systems, compilers, and many, many applications. He began developing Windows applications using a beta version of Windows 1.0. Brent is the founder of Wise Owl Consulting, Inc. (http://www.wiseowl.com), and the architect and primary developer of Demeanor for .NET, Enterprise Edition—the premier .NET code obfuscator. In addition, Brent is an instructor for Wintellect (http://www.wintellect.com). He has also written several books on Windows programming, including ATL Internals, Win32 Programming, and others.

# # #

Page 2 of 2

This article was originally published on June 14, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date