3

As far as I know, if we're dealing with COM interfaces, any simple cast will usually trigger the QueryInterface routine, which is used to determine if the object actually implements the corresponding COM interface.

object whatever;
IComInterface casted = (IComInterface) whatever;

Hence, the following code, depending on the compiler and optimizations might trigger the QueryInterface in the internal object casting implementation:

IComInterface comInteface;

// I guess nothing COM-related happens here, but I might be wrong
object whatever = comInteface; 

// This might or might not trigger the 'QueryInterface' call.
IComInterface comInterface2 = (IComInteface) whatever;

Q:

Suppose I have a generic List<T> instance: 

List<IComInterface> list = new List<IComInterface>();

Now, do I have a strong guarantee that the following code would not trigger the QueryInterface-based cast?

List<IComInterface> list = new List<IComInterface>();
IComInterface comInterface = (...); // Somehow got it.
list.Add(comInteface);
IComInterface retrieved = list[0];

  • Using ArrayList instead of List<T> here actually results in the cast performed, because you have to get the corresponding IComInterface from your typeless object instance.

  • However, in case of generics, I guess, everything should be done without casting, but I'm not actually sure about how they work under the surface.

  • Is it possible that List<T> still somehow operates with object types (and, hence, will invoke the QueryInterface-based cast in the described scenario)?

  • If the answer to the previous question is "no", is it true, that you can't guarantee the same for any possible IList<T>?

Yippie-Ki-Yay
  • 22,026
  • 26
  • 90
  • 148
  • As far as I know I thought that .NET created an instance of a new type when you created a generic type - therefore the strongly typed generic won't use `System.Object` references - I may be wrong – Charleh Jul 12 '12 at 12:24
  • I am not 100% sure about it, so writing comment, One thing is no casting will happen if you use List another is that your second question is irrelevant cause List implements IList. – Guru Kara Jul 12 '12 at 12:25
  • @GuruKara Second question, as I realize now, is stupid, because somebody can implement a `IList`, which uses `object` to store data and then casts it back :) So, I guess, the question is only about `List`. – Yippie-Ki-Yay Jul 12 '12 at 12:27
  • It might be worth reading this: http://www.artima.com/intv/generics2.html - It seems to shed some light on what IL is generated and what the CLR is actually doing. Sounds like each generic type is treated separately - give it a read – Charleh Jul 12 '12 at 12:28
  • 3
    The interesting bit is: Bruce Eckel: And you just need to cast. Anders Hejlsberg: No, you don't actually. We can share the native image, but they actually have separate VTables. I'm just pointing out that we do fairly aggressive code sharing where it makes sense, but we are also very conscious about not sharing where you want the performance. Typically with value types, you really do care that List is int. You don't want them to be boxed as Objects. Boxing value types is one way we could share, but boy it would be an expensive way. – Charleh Jul 12 '12 at 12:29

2 Answers2

2

You can think of generic type instances (e.g. List<IComInterface>) as of classes created from generic type definitions (e.g. List<T>) by literally replacing the name T with the name IComInterface. The type is not "erased" the way it is done in some languages (most notably, Java), it is kept with the generic type instance, so that all variables declared as type T in the generic type definition remain strongly typed in the generic type instance.

In case of a List<IComInterface>, there is no cast to or from object as long as you insert objects that are known to be of IComInterface type at compile time. This is the case in the code from your post, but it may not always be true. For example, when you insert a dynamically typed object, the compiler will add a cast:

dynamic comInteface = ...
list.Add(comInteface); // There will be an implicit cast here
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
1

Yes, that's a pretty decent guarantee, the compiler won't emit a Opcodes.Castclass IL instruction unless it has to. The type matches so no need to for the cast.

This should not in general concern you. The QI implementation of a COM interface gets hammered for all kinds of reasons, internal to COM. It is always very fast, comparing a guid takes but a handful of nanoseconds.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thank you, the question was purely academic and I was not concerned with the performance of the cast (that would obviously be premature). – Yippie-Ki-Yay Jul 12 '12 at 12:35
  • Odd, if it is not perf then why are you academically interested? Kinda hard to properly answer balloon questions. – Hans Passant Jul 12 '12 at 12:39