Resolved MethodDefinition for System.Collections.Generic.List.Add has IsVirtual = true #149

Closed
opened 2013-12-30 17:19:44 -06:00 by kg · 2 comments
kg commented 2013-12-30 17:19:44 -06:00 (Migrated from github.com)

I'm trying to figure out why this would be the case. System.Collections.Generic.List.Add is very definitely not virtual, here's the source from mono's corlib implementation:

                public void Add (T item)
                {
                        // If we check to see if we need to grow before trying to grow
                        // we can speed things up by 25%
                        if (_size == _items.Length)
                                GrowIfNeeded (1);
                        _items [_size++] = item;
                        _version++;
                }

However, Cecil says that it is virtual when I resolve a MethodReference and get a MethodDefinition for the method. The MethodDefinition is definitely coming from mscorlib and it points to the expected method.

Is this an expected behavior? The only explanation I can think of is that Add silently becomes virtual because it is being used to implement an 'Add' method on some particular interface, but that seems counterintuitive and I've never seen it specified as 'correct' behavior.

I'm trying to figure out why this would be the case. System.Collections.Generic.List.Add is very definitely _not_ virtual, here's the source from mono's corlib implementation: ``` csharp public void Add (T item) { // If we check to see if we need to grow before trying to grow // we can speed things up by 25% if (_size == _items.Length) GrowIfNeeded (1); _items [_size++] = item; _version++; } ``` However, Cecil says that it is virtual when I resolve a MethodReference and get a MethodDefinition for the method. The MethodDefinition is definitely coming from mscorlib and it points to the expected method. Is this an expected behavior? The only explanation I can think of is that Add silently becomes virtual because it is being used to implement an 'Add' method on some particular interface, but that seems counterintuitive and I've never seen it specified as 'correct' behavior.
jbevain commented 2014-01-04 08:48:41 -06:00 (Migrated from github.com)

Yeah it's expected :)

    .method public final virtual hidebysig newslot 
           instance default void Add (!T item)  cil managed 

The method implicitly implements ICollection`1.Add and needs a slot in the vtable to be called if called through the interface.

Yeah it's expected :) ``` .method public final virtual hidebysig newslot instance default void Add (!T item) cil managed ``` The method implicitly implements ICollection`1.Add and needs a slot in the vtable to be called if called through the interface.
kg commented 2014-01-04 15:09:47 -06:00 (Migrated from github.com)

Thanks, that makes more sense. I should have checked the IL.

Thanks, that makes more sense. I should have checked the IL.
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-jbevain/cecil#149
No description provided.