Можете ли вы иметь класс в структуре?

Да, ты можешь. Указатель на переменную-член класса хранится в в стеке вместе с остальными значениями структуры, а данные экземпляра класса хранятся в куче.

Структуры также могут содержать определения классов в качестве членов (внутренние классы).

Вот действительно бесполезный код, который, по крайней мере, компилируется и запускается, чтобы показать, что это возможно:

using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            MyStr m = new MyStr();
            m.Foo();

            MyStr.MyStrInner mi = new MyStr.MyStrInner();
            mi.Bar();

            Console.ReadLine();
        }
    }

    public class Myclass
    {
        public int a;
    }

    struct MyStr
    {
        Myclass mc;

        public void Foo()
        {
            mc = new Myclass();
            mc.a = 1;
        }

        public class MyStrInner
        {
            string x = "abc";

            public string Bar()
            {
                return x;
            }
        }
    }
}

Это, вероятно, не рекомендуется: см. http://msdn.microsoft.com/en-us/library/ms229017(VS.85).aspx

Reference types are allocated on the heap, and memory management is handled by the garbage collector.

Value types are allocated on the stack or inline and are deallocated when they go out of scope.

In general, value types are cheaper to allocate and deallocate. However, if they are used in scenarios that require a significant amount of boxing and unboxing, they perform poorly as compared to reference types.

Содержимое класса сохраняется в куче.

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

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

Как правило, следует избегать хранения изменяемых типов классов в структуре, если не применяется одна из двух ситуаций:

1. Фактически, нас интересует идентификация объекта класса, а не его содержимое. Например, можно определить структуру `FormerControlBounds`, которая содержит поля типа` Control` и `Rectangle` и представляет` Bounds`, которые элемент управления имел в какой-то момент времени, с целью иметь возможность позже восстановить элемент управления. к его более раннему положению. Поле `Control` предназначено не для хранения копии состояния элемента управления, а скорее для идентификации элемента управления, положение которого следует восстановить. Как правило, структура должна избегать доступа к любым изменяемым членам объекта, на который она содержит ссылку, за исключением случаев, когда ясно, что такой доступ относится к текущему изменяемому состоянию рассматриваемого объекта (например, в `CaptureControlPosition` или` RestoreControlToCapturedPosition или свойство ControlHasMoved).
2. Поле является `частным`, единственные методы, которые его читают, делают это с целью изучения его свойств, не подвергая сам объект его внешнему коду, и единственные методы, которые его пишут, будут создавать новый объект, выполнять все мутации. которые когда-либо с ним произойдут, а затем сохраните ссылку на этот объект. Можно, например, разработать структуру, которая ведет себя так же, как массив, но с семантикой значений, если структура будет удерживать массив в частном поле, и каждая попытка записи массива создает новый массив с данными. из старого, измените новый массив и сохраните измененный массив в этом поле. Обратите внимание, что даже если сам массив будет изменяемым типом, каждый экземпляр массива, который когда-либо будет храниться в поле, будет фактически неизменяемым, поскольку он никогда не будет доступен для любого кода, который может его изменить.

Обратите внимание, что сценарий №1 довольно часто встречается с универсальными типами; например, очень часто бывает словарь, «значения» которого являются идентификаторами изменяемых объектов; перечисление этого словаря вернет экземпляры KeyValuePair, чье поле Value содержит этот изменяемый тип.

Сценарий № 2 встречается реже. Увы, нет способа сообщить компилятору, что методы структуры, отличные от средств установки свойств, будут изменять структуру, и поэтому их использование должно быть запрещено в контекстах только для чтения; можно было бы иметь структуру, которая вела бы себя как List<T>, но с семантикой значений и включала метод Add, но попытка вызвать Add в экземпляре структуры, доступной только для чтения, сгенерирует фиктивный код, а не ошибку компилятора. Кроме того, методы изменения и установщики свойств в таких структурах обычно работают довольно плохо. Такие структуры могут быть полезны, когда они существуют как неизменяемая оболочка для изменяемого в противном случае класса; если такая структура никогда не помещается в коробку, производительность часто будет лучше, чем у класса. Если упакован ровно один раз (например, при приведении к типу интерфейса), производительность, как правило, будет сопоставима с классом. При повторной упаковке производительность может быть намного хуже, чем у класса.