Як масиви в 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.

То чому дивацтво? Ну, я вважаю, що це дійсно пов'язано з коваріацією масиву, яка є бородавкою в системі типів, IMO. Незважаючи на те, що IList<T>він не є коваріантним (і не може бути безпечним), коваріація масиву дозволяє це працювати:

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

... що робить його виглядати як typeof(string[])знаряддя IList<object>, коли це не на самому ділі.

Розділ 8.7.1 специфікації CLI (ECMA-335), розділ 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 робить певне відображення, щоб зберегти сумісність призначення тут: коли 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 <>. Це не може, масив не є загальним. Те саме стосується загальних інтерфейсів 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 <> і каже "добре, я знаю, як це зробити!". І випускає інструкцію ІЛ з каскаду. З 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 .dt замінюється там. Наприклад, 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>обробляється так, як внизу описується Ганс .

Явна реалізація інтерфейсу . Коротше кажучи, ви заявляєте це як 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, знаходить відповідний загальний метод (відповідний просто за назвою методу) , інстанціює його для типу та виконує його.

(Наголос мій)

Джерело (прокручування вгору).