Как массивы в C # частично реализуют IList <T>?

Итак, как вы, возможно, знаете, массивы в C # реализуются IList<T>среди других интерфейсов. Однако каким-то образом они делают это без публичной реализации свойства Count IList<T>! У массивов есть только свойство Length.

Это вопиющий пример того, как C # /. NET нарушает собственные правила реализации интерфейса, или я чего-то упускаю?

Новый ответ в свете ответа Ганса

Благодаря ответу Ханса мы видим, что реализация несколько сложнее, чем мы думали. И компилятор, и среда CLR очень стараются создать впечатление, что тип массива реализует, IList<T>но дисперсия массива делает это сложнее. В отличие от ответа Ханса, типы массивов (одномерные, в любом случае с нулевым отсчетом) реализуют общие коллекции напрямую, потому что тип какого-либо конкретного массива не является System.Array - это просто базовый тип массива. Если вы спросите тип массива, какие интерфейсы он поддерживает, он включает в себя общие типы:

foreach (var type in typeof(int[]).GetInterfaces())
{
    Console.WriteLine(type);
}

Вывод:

System.ICloneable
System.Collections.IList
System.Collections.ICollection
System.Collections.IEnumerable
System.Collections.IStructuralComparable
System.Collections.IStructuralEquatable
System.Collections.Generic.IList`1[System.Int32]
System.Collections.Generic.ICollection`1[System.Int32]
System.Collections.Generic.IEnumerable`1[System.Int32]

Для одномерных массивов, начинающихся с нуля, с точки зрения языка , массив действительно также реализуется IList<T>. Об этом говорится в разделе 12.1.2 спецификации C #. Таким образом, что бы ни делала базовая реализация, язык должен вести себя так, как если бы этот тип T[]реализован, IList<T>как и любой другой интерфейс. С этой точки зрения, интерфейс будет реализован с некоторыми из членов которые явно реализованы (например Count). Это лучшее объяснение происходящего на языковом уровне.

Обратите внимание, что это справедливо только для одномерных массивов (и массивов с нулевым отсчетом, а не то, что C # как язык говорит что-либо о ненулевых массивах). T[,] не реализует IList<T>.

С точки зрения CLR происходит нечто более забавное. Вы не можете получить отображение интерфейса для универсальных типов интерфейса. Например:

typeof(int[]).GetInterfaceMap(typeof(ICollection<int>))

Дает исключение:

Unhandled Exception: System.ArgumentException: Interface maps for generic
interfaces on arrays cannot be retrived.

Так к чему странность? Ну, я считаю, что это действительно связано с ковариацией массивов, которая является бородавкой в ​​системе типов, ИМО. Несмотря на то, что ковариантность неIList<T> является ковариантной (и не может быть безопасной), ковариация массива позволяет этому работать:

string[] strings = { "a", "b", "c" };
IList<object> objects = strings;

... что делает его похожим на typeof(string[])орудие труда IList<object>, хотя на самом деле это не так.

Спецификация CLI (ECMA-335), раздел 1, раздел 8.7.1, имеет следующее:

Тип подписи T совместим с типом подписи U тогда и только тогда, когда выполняется хотя бы одно из следующего:

...

T - это массив с рангом 1, отсчитываемый от нуля V[], и Uравен IList<W>, а V является совместимым по элементам массива с W.

(На самом деле здесь не упоминается ICollection<W>или, как IEnumerable<W>я считаю, ошибка в спецификации.)

В случае отсутствия вариативности спецификация CLI идет вместе со спецификацией языка. Из раздела 8.9.1 раздела 1:

Кроме того, созданный вектор с типом элемента T реализует интерфейс System.Collections.Generic.IList<U>, где U: = T. (§8.7)

( Вектор - это одномерный массив с нулевым основанием.)

Теперь, что касается деталей реализации , ясно, что CLR выполняет некое фанковое отображение, чтобы сохранить здесь совместимость присваивания: когда a string[]запрашивается реализация ICollection<object>.Count, он не может справиться с этим вполне обычным способом. Считается ли это явной реализацией интерфейса? Я думаю, что разумно относиться к этому так, поскольку, если вы не запрашиваете отображение интерфейса напрямую, он всегда ведет себя таким образом с точки зрения языка.

О чем ICollection.Count?

До сих пор я говорил об общих интерфейсах, но есть еще неуниверсальный ICollectionсо своим Countсвойством. На этот раз мы можем получить отображение интерфейса, и на самом деле интерфейс реализуется напрямую с помощью System.Array. В документации для ICollection.Countреализации свойства Arrayуказано, что оно реализовано с явной реализацией интерфейса.

Если кто-нибудь может придумать, чем такая явная реализация интерфейса отличается от «нормальной» явной реализации интерфейса, я был бы счастлив изучить ее подробнее.

Старый ответ о явной реализации интерфейса

Несмотря на вышесказанное, что является более сложным из-за знания массивов, вы все равно можете делать что-то с теми же видимыми эффектами посредством явной реализации интерфейса .

Вот простой автономный пример:

public interface IFoo
{
    void M1();
    void M2();
}

public class Foo : IFoo
{
    // Explicit interface implementation
    void IFoo.M1() {}

    // Implicit interface implementation
    public void M2() {}
}

class Test    
{
    static void Main()
    {
        Foo foo = new Foo();

        foo.M1(); // Compile-time failure
        foo.M2(); // Fine

        IFoo ifoo = foo;
        ifoo.M1(); // Fine
        ifoo.M2(); // Fine
    }
}

Как вы, возможно, знаете, массивы в C # реализуют IList<T>среди других интерфейсов

Ну да, эм нет, не совсем. Это объявление класса Array в платформе .NET 4:

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

Он реализует System.Collections.IList, а не System.Collections.Generic.IList <>. Не может, Array не является универсальным. То же самое касается универсальных интерфейсов IEnumerable <> и ICollection <>.

Но среда CLR создает конкретные типы массивов на лету, так что технически она может создать массив, реализующий эти интерфейсы. Однако это не так. Попробуйте, например, этот код:

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(); }
}

Вызов GetInterfaceMap () не выполняется для конкретного типа массива с сообщением «Интерфейс не найден». Однако приведение к IEnumerable <> работает без проблем.

Это шарлатанский набор текста. Это тот же тип ввода, который создает иллюзию, что каждый тип значения является производным от ValueType, производного от Object. И компилятор, и среда CLR обладают специальными знаниями о типах массивов, как и о типах значений. Компилятор видит вашу попытку преобразования в IList <> и говорит: «Хорошо, я знаю, как это сделать!». И испускает инструкцию castclass IL. У CLR нет проблем с этим, она знает, как предоставить реализацию IList <>, которая работает с базовым объектом массива. Он имеет встроенные сведения о скрытом в противном случае классе System.SZArrayHelper, оболочке, которая фактически реализует эти интерфейсы.

Что явно не так, как утверждают все, свойство Count, о котором вы спрашивали, выглядит следующим образом:

    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;
    }

Да, этот комментарий можно назвать "нарушением правил" :) В остальном он чертовски удобен. И очень хорошо скрытый, вы можете проверить это в SSCLI20, дистрибутиве с общим исходным кодом для CLR. Найдите «IList», чтобы увидеть, где происходит замена типа. Лучше всего увидеть его в действии - это метод clr ​​/ src / vm / array.cpp, GetActualImplementationForArrayGenericIListMethod ().

Такая замена в CLR довольно мягкая по сравнению с тем, что происходит в языковой проекции в CLR, которая позволяет писать управляемый код для WinRT (также известного как Metro). Здесь заменяется практически любой базовый тип .NET. IList <> отображается на IVector <>, например, полностью неуправляемый тип. Сам по себе подстановка, COM не поддерживает универсальные типы.

Что ж, это был взгляд на то, что происходит за занавеской. Это могут быть очень неудобные, странные и незнакомые моря с драконами, живущими в конце карты. Может быть очень полезно сделать Землю плоской и смоделировать другое изображение того, что на самом деле происходит в управляемом коде. Так удобно сопоставить его со всеми любимыми ответами. Что не так хорошо работает для типов значений (не изменяйте структуру!), Но это очень хорошо скрыто. Ошибка метода GetInterfaceMap () - единственная утечка в абстракции, о которой я могу думать.

IList<T>.Countреализовано явно :

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

Это сделано для того, чтобы при наличии простой переменной массива у вас не было сразу и того, Countи другого Length.

В общем случае явная реализация интерфейса используется, когда вы хотите гарантировать, что тип можно использовать определенным образом, не заставляя всех потребителей этого типа думать об этом таким образом.

Изменить : Упс, там плохой отзыв. ICollection.Countреализовано явно. Родовым IList<T>обрабатываются как Hans descibes ниже .

Явная реализация интерфейса . Короче декларируете как void IControl.Paint() { }или int IList<T>.Count { get { return 0; } }.

Это ничем не отличается от явной реализации интерфейса IList. Тот факт, что вы реализуете интерфейс, не означает, что его члены должны отображаться как члены класса. Он действительно реализует свойство Count, но не предоставляет его в X [].

При наличии справочников:

//----------------------------------------------------------------------------------------
// ! 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 ... */
}

В частности, эта часть:

диспетчер заглушки интерфейса рассматривает это как особый случай , загружает SZArrayHelper, находит соответствующий универсальный метод (сопоставленный просто по имени метода) , создает его для типа и выполняет.

(Акцент мой)

Источник (прокрутите вверх).