Почему структуры не поддерживают наследование?

Представьте, что структуры поддерживают наследование. Затем объявление:

BaseStruct a;
InheritedStruct b; //inherits from BaseStruct, added fields, etc.

a = b; //?? expand size during assignment?

означало бы, что структурные переменные не имеют фиксированного размера, и именно поэтому у нас есть ссылочные типы.

Еще лучше, рассмотрите следующее:

BaseStruct[] baseArray = new BaseStruct[1000];

baseArray[500] = new InheritedStruct(); //?? morph/resize the array?

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

Вот что сказано в документации :

Структуры особенно полезно для небольших структур данных, имеющих семантику значений. Комплексные числа, точки в системе координат или пары ключ-значение в словаре - все это хорошие примеры структур. Ключом к этим структурам данных является то, что у них мало членов данных, что они не требуют использования наследования или ссылочной идентичности и что они могут быть удобно реализованы с использованием семантики значений, когда присваивание копирует значение вместо ссылки.

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

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

Структуры действительно поддерживают интерфейсы, поэтому таким образом можно делать некоторые полиморфные вещи.

IL - это стековый язык, поэтому вызов метода с аргументом происходит примерно так:

1. Помещать аргумент в стек
2. Вызвать метод.

Когда метод запускается, он извлекает из стека несколько байтов, чтобы получить свой аргумент. Он знает точно , сколько байтов нужно извлечь, потому что аргумент является либо указателем ссылочного типа (всегда 4 байта на 32-битном), либо типом значения, размер которого всегда точно известен.

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

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

Класс, подобный наследованию, невозможно, поскольку структура накладывается непосредственно на стек. Наследующая структура будет больше, чем родительская, но JIT этого не знает и пытается разместить слишком много на слишком маленьком пространстве. Звучит немного непонятно, давайте напишем пример:

struct A {
    int property;
} // sizeof A == sizeof int

struct B : A {
    int childproperty;
} // sizeof B == sizeof int * 2

Если бы это было возможно, он бы вылетел из следующего фрагмента:

void DoSomething(A arg){};

...

B b;
DoSomething(b);

Пространство выделяется для размера A, а не для размера B.

Есть момент, который я хотел бы исправить. Хотя структуры не могут быть унаследованы, потому что они живут в стеке, это правильное объяснение, но в то же время это наполовину правильное объяснение. Структуры, как и любой другой тип значения , могут находиться в стеке. Поскольку это будет зависеть от того, где объявлена ​​переменная, они будут находиться либо в стеке , либо в куче . Это будет, когда они являются локальными переменными или полями экземпляра соответственно.

Сказав, что Сесил имеет имя, это правильно.

Я хотел бы это подчеркнуть, типы значений могут находиться в стеке. Это не значит, что они всегда так делают. Локальные переменные, включая параметры метода, будут. Все остальные не будут. Тем не менее, это все еще причина, по которой они не могут быть переданы по наследству. : -)

Structs are allocated on the stack. This means the value semantics are pretty much free, and accessing struct members is very cheap. This doesn't prevent polymorphism.

You could have each struct start with a pointer to its virtual function table. This would be a performance issue (every struct would be at least the size of a pointer), but it's doable. This would allow virtual functions.

What about adding fields?

Well, when you allocate a struct on the stack, you allocate a certain amount of space. The required space is determined at compile time (whether ahead of time or when JITting). If you add fields and then assign to a base type:

struct A
{
    public int Integer1;
}

struct B : A
{
    public int Integer2;
}

A a = new B();

This will overwrite some unknown part of the stack.

The alternative is for the runtime to prevent this by only writing sizeof(A) bytes to any A variable.

What happens if B overrides a method in A and references its Integer2 field? Either the runtime throws a MemberAccessException, or the method instead accesses some random data on the stack. Neither of these is permissible.

It's perfectly safe to have struct inheritance, so long as you don't use structs polymorphically, or so long as you don't add fields when inheriting. But these aren't terribly useful.

Этот вопрос кажется очень частым. Мне хочется добавить, что типы значений хранятся «на месте», где вы объявляете переменную; помимо деталей реализации, это означает, что отсутствует заголовок объекта, который что-то говорит об объекте, только переменная знает, какие данные там находятся.