Jak tablice w C# częściowo implementują IList?

Więc jak zapewne wiesz, tablice w C# implementują IList<T>, między innymi interfejsy

[Serializable, ComVisible(true)]
public abstract class Array : ICloneable, IList, ICollection, IEnumerable, 
                              IStructuralComparable, IStructuralEquatable
{
    // etc..
}

Implementuje System.Kolekcje.IList, Nie System.Kolekcje.Ogólne.IList. Nie może, tablica nie jest ogólna. To samo dotyczy ogólnych interfejsów IEnumerable i ICollection.

Ale CLR tworzy konkretne typy tablic w locie, więc może technicznie stworzyć taki, który implementuje te interfejsy. Tak jednak nie jest. Wypróbuj ten kod na przykład:

using System;
using System.Collections.Generic;

class Program {
    static void Main(string[] args) {
        var goodmap = typeof(Derived).GetInterfaceMap(typeof(IEnumerable<int>));
        var badmap = typeof(int[]).GetInterfaceMap(typeof(IEnumerable<int>));  // Kaboom
    }
}
abstract class Base { }
class Derived : Base, IEnumerable<int> {
    public IEnumerator<int> GetEnumerator() { return null; }
    System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return GetEnumerator(); }
}

Wywołanie GetInterfaceMap() nie powiedzie się dla konkretnego typu tablicy z "Interface not found". Jednak Obsada do Ieenumerable działa bez problemu.

To jest quacks-like-a-duck typing. Jest to ten sam rodzaj typowania, który tworzy iluzję, że każdy typ wartości pochodzi od ValueType, który pochodzi od obiektu. Zarówno kompilator jak i CLR mają specjalne znajomość typów tablic, podobnie jak typów wartości. Kompilator widzi Twoją próbę castingu do IList i mówi: "OK, wiem jak to zrobić!". I emituje instrukcję castlass IL. CLR nie ma z tym problemu, wie jak dostarczyć implementację IList, która działa na bazowym obiekcie array. Posiada wbudowaną wiedzę o ukrytym systemie.Klasa SZArrayHelper, wrapper, który faktycznie implementuje te interfejsy.

Czego nie robi wprost jak wszyscy twierdzą, nieruchomość Count, o którą pytałeś, wygląda tak:

    internal int get_Count<T>() {
        //! Warning: "this" is an array, not an SZArrayHelper. See comments above
        //! or you may introduce a security hole!
        T[] _this = JitHelpers.UnsafeCast<T[]>(this);
        return _this.Length;
    }

Tak, na pewno można nazwać ten komentarz "łamaniem zasad":) jest inaczej cholernie przydatny. I bardzo dobrze ukryte, można to sprawdzić w SSCLI20, współdzielonej dystrybucji źródłowej dla CLR. Wyszukaj "IList", aby zobaczyć, gdzie ma miejsce podstawianie typu. Najlepszym miejscem, aby zobaczyć go w akcji jest clr / src/vm / array.cpp, GetActualImplementationForArrayGenericilistmethod() metoda.

Tego rodzaju substytucja w CLR jest dość łagodna w porównaniu do tego, co dzieje się w projekcji języka w CLR, która umożliwia pisanie zarządzanego kodu dla WinRT (aka Metro). Prawie każdy rdzeń typu. NET jest tam zastępowany. IList maps to IVector na przykład, całkowicie niezarządzany Typ. Sam substytut, COM NIE obsługuje typów generycznych.

IList<T>.Count jest realizowany jawnie:

int[] intArray = new int[10];
IList<int> intArrayAsList = (IList<int>)intArray;
Debug.Assert(intArrayAsList.Count == 10);

Jest to zrobione tak, że gdy masz prostą zmienną tablicy, nie masz zarówno Count, jak i Length bezpośrednio dostępnych.

Ogólnie rzecz biorąc, implementacja interfejsu jawnego jest używana, gdy chcesz zapewnić, że typ może być używany w określony sposób, bez zmuszania wszystkich konsumentów tego typu do myślenia o tym w ten sposób.

Edit : UPS, złe przypomnienie tam. {[4] } jest zaimplementowane jawnie. Na generic IList<T> jest traktowany jako Hans descibes poniżej .

Explicit interface implementation . Krótko mówiąc, deklarujesz to jako void IControl.Paint() { } LUB int IList<T>.Count { get { return 0; } }.

Nie różni się niczym od jawnej implementacji interfejsu IList. Tylko dlatego, że zaimplementowałeś interfejs, nie oznacza to, że jego członkowie muszą pojawiać się jako członkowie klasy. To robi implementuje właściwość Count, po prostu nie wystawia jej Na x [].

Z dostępnymi źródłami odniesienia:

//----------------------------------------------------------------------------------------
// ! READ THIS BEFORE YOU WORK ON THIS CLASS.
// 
// The methods on this class must be written VERY carefully to avoid introducing security holes.
// That's because they are invoked with special "this"! The "this" object
// for all of these methods are not SZArrayHelper objects. Rather, they are of type U[]
// where U[] is castable to T[]. No actual SZArrayHelper object is ever instantiated. Thus, you will
// see a lot of expressions that cast "this" "T[]". 
//
// This class is needed to allow an SZ array of type T[] to expose IList<T>,
// IList<T.BaseType>, etc., etc. all the way up to IList<Object>. When the following call is
// made:
//
//   ((IList<T>) (new U[n])).SomeIListMethod()
//
// the interface stub dispatcher treats this as a special case, loads up SZArrayHelper,
// finds the corresponding generic method (matched simply by method name), instantiates
// it for type <T> and executes it. 
//
// The "T" will reflect the interface used to invoke the method. The actual runtime "this" will be
// array that is castable to "T[]" (i.e. for primitivs and valuetypes, it will be exactly
// "T[]" - for orefs, it may be a "U[]" where U derives from T.)
//----------------------------------------------------------------------------------------
sealed class SZArrayHelper {
    // It is never legal to instantiate this class.
    private SZArrayHelper() {
        Contract.Assert(false, "Hey! How'd I get here?");
    }

    /* ... snip ... */
}

Konkretnie ta część:

Dyspozytor interfejsu stub traktuje to jako szczególny przypadek , ładuje SZArrayHelper, znajduje odpowiednią metodę generyczną (dopasowaną po prostu przez nazwę metody) , tworzy instancję dla type i wykonuje ją.

(moje)

Źródło (przewiń w górę).