Когда вы должны использовать структуру, а не класс в C #? Моя концептуальная модель состоит в том, что структуры используются во времена, когда элемент представляет собой просто набор типов значений . Способ логически объединить их все в единое целое.

Я столкнулся с этими правилами здесь :

• Структура должна представлять одно значение.
• Структура должна иметь объем памяти менее 16 байт.
• Структура не должна быть изменена после создания.

Эти правила работают? Что означает семантически структура?

Источник, на который ссылается OP, заслуживает доверия ... но как насчет Microsoft - какова позиция по использованию структуры? Я искал дополнительное обучение у Microsoft , и вот что я нашел:

Попробуйте определить структуру вместо класса, если экземпляры типа маленькие и обычно недолговечные или обычно встроены в другие объекты.

Не определяйте структуру, если тип не имеет всех следующих характеристик:

1. Он логически представляет одно значение, похожее на примитивные типы (целое, двойное и т. Д.).
2. Размер экземпляра меньше 16 байт.
3. Это неизменно.
4. Это не должно быть упаковано часто.

Microsoft постоянно нарушает эти правила

Хорошо, № 2 и № 3 в любом случае. Наш любимый словарь имеет 2 внутренних структуры:

[StructLayout(LayoutKind.Sequential)]  // default for structs
private struct Entry  //<Tkey, TValue>
{
    //  View code at *Reference Source
}

[Serializable, StructLayout(LayoutKind.Sequential)]
public struct Enumerator : 
    IEnumerator<KeyValuePair<TKey, TValue>>, IDisposable, 
    IDictionaryEnumerator, IEnumerator
{
    //  View code at *Reference Source
}

* Справочный источник

Источник 'JonnyCantCode.com' получил 3 из 4 - вполне простительно, поскольку № 4, вероятно, не будет проблемой. Если вы обнаружите, что занимаетесь структурой, переосмыслите свою архитектуру.

Давайте посмотрим, почему Microsoft будет использовать эти структуры:

1. Каждая структура EntryиEnumerator представляет отдельные значения.
2. скорость
3. Entryникогда не передается как параметр вне класса Dictionary. Дальнейшие исследования показывают, что для удовлетворения реализации IEnumerable словарь использует Enumeratorструктуру, которую он копирует каждый раз при запросе перечислителя ... имеет смысл.
4. Внутренний в классе словаря. Enumeratorявляется общедоступным, поскольку Dictionary является перечислимым и должен иметь равный доступ к реализации интерфейса IEnumerator, например, к получателю IEnumerator.

Обновление. Кроме того, следует понимать, что когда структура реализует интерфейс - как это делает Enumerator - и приводится к этому реализованному типу, структура становится ссылочным типом и перемещается в кучу. Внутренний по отношению к классу Dictionary, Enumerator по- прежнему является типом значения. Однако, как только метод вызывает GetEnumerator(), ссылочный типIEnumerator возвращается .

Здесь мы не видим каких-либо попыток или доказательств необходимости сохранять неизменяемыми структуры или поддерживать размер экземпляра не более 16 байт:

1. Ничто в вышеприведенных структурах не заявлено readonly- не является неизменным
2. Размер этой структуры может быть более 16 байтов
3. Entryимеет неопределенный срок службы (от Add(), до Remove(), Clear()или мусора);

И ... 4. Обе структуры хранят TKey и TValue, которые, как мы все знаем, вполне могут быть ссылочными типами (дополнительная информация о бонусе)

Несмотря на хешированные ключи, словари работают быстро, потому что создание структуры быстрее, чем ссылочного типа. Здесь у меня есть, Dictionary<int, int>который хранит 300 000 случайных целых чисел с последовательно увеличенными ключами.

Емкость: 312874
MemSize: 2660827 байт
Выполнено Размер: 5мс
Общее время заполнения: 889мс

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

Memsize : определяется путем сериализации словаря в MemoryStream и получения длины в байтах (достаточно точной для наших целей).

Завершено Изменение размера : время, необходимое для изменения размера внутреннего массива с 150862 элементов до 312874 элементов. Когда вы понимаете, что каждый элемент последовательно копируется черезArray.CopyTo() , это не так уж и плохо.

Общее время для заполнения : по общему признанию искажено из-за регистрации и OnResizeсобытия, которое я добавил к источнику; Тем не менее, по-прежнему впечатляет заполнить 300 тысяч целых чисел при изменении размера в 15 раз во время операции Просто из любопытства, сколько будет общего времени, чтобы заполнить, если бы я уже знал емкость? 13 мс

Итак, что теперь, если бы Entryбыл класс? Будут ли эти времена или показатели действительно сильно отличаться?

Емкость: 312874
MemSize: 2660827 байт
Выполнено Размер: 26мс
Общее время заполнения: 964мс

Очевидно, большая разница заключается в изменении размера. Есть ли разница, если словарь инициализируется с Capacity? Не достаточно, чтобы беспокоиться о ... 12 мс .

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

/*
 *  Added to satisfy initialization of entry elements --
 *  this is where the extra time is spent resizing the Entry array
 * **/
for (int i = 0 ; i < prime ; i++)
{
    destinationArray[i] = new Entry( );
}
/*  *********************************************** */  

Причину, по которой мне нужно было инициализировать каждый элемент массива Entryв качестве ссылочного типа, можно найти в MSDN: Конструкция структуры . Короче говоря:

Не предоставляйте конструктор по умолчанию для структуры.

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

Некоторые компиляторы, такие как компилятор C #, не позволяют структурам иметь конструкторы по умолчанию.

Это на самом деле довольно просто , и мы будем брать из Азимова три закона робототехники :

1. Структура должна быть безопасной для использования
2. Структура должна эффективно выполнять свою функцию, если это не нарушит правило № 1
3. Структура должна оставаться неизменной во время ее использования, если ее уничтожение не требуется для удовлетворения правила # 1

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

Всякий раз, когда вам:

1. не нужен полиморфизм,
2. хотите семантику значения, и
3. хочу избежать выделения кучи и связанных с этим издержек сборки мусора.

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

Я не согласен с правилами, приведенными в оригинальном посте. Вот мои правила:

1) Вы используете структуры для производительности при хранении в массивах. (см. также, Когда составляется ответ? )

2) Они нужны вам при передаче кода структурированных данных в / из C / C ++

3) Не используйте структуры, если они вам не нужны:

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

Используйте структуру, когда вам нужна семантика значений, а не ссылочная семантика.

редактировать

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

Если вам нужна ссылочная семантика, вам нужен класс, а не структура.

В дополнение к ответу «это значение», один конкретный сценарий использования структур - это когда вы знаете, что у вас есть набор данных, вызывающий проблемы со сборкой мусора, и у вас много объектов. Например, большой список / массив экземпляров Person. Естественной метафорой здесь является класс, но если у вас есть большое количество долгоживущих экземпляров Person, они могут в конечном итоге засорить GEN-2 и вызвать остановку GC. Если варранты сценарии, один из возможных подходов здесь использовать массив (не список) Person структура , то есть Person[]. Теперь, вместо миллионов объектов в GEN-2, у вас есть отдельный кусок в LOH (я предполагаю, что здесь нет строк и т. Д., Т.е. чистое значение без каких-либо ссылок). Это имеет очень небольшое влияние GC.

Работать с этими данными неудобно, поскольку данные, вероятно, слишком велики для структуры, и вы не хотите постоянно копировать жирные значения. Однако доступ к нему напрямую в массиве не копирует структуру - она ​​на месте (в отличие от индексатора списка, который копирует). Это означает большую работу с индексами:

int index = ...
int id = peopleArray[index].Id;

Обратите внимание, что поддержание неизменности самих значений поможет здесь. Для более сложной логики используйте метод с параметром by-ref:

void Foo(ref Person person) {...}
...
Foo(ref peopleArray[index]);

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

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

Из спецификации языка C # :

1.7 Структуры

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

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

class Point
{
   public int x, y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }
}

class Test
{
   static void Main() {
      Point[] points = new Point[100];
      for (int i = 0; i < 100; i++) points[i] = new Point(i, i);
   }
}

Альтернатива - сделать Point структурой.

struct Point
{
   public int x, y;

   public Point(int x, int y) {
      this.x = x;
      this.y = y;
   }
}

Теперь создается только один объект - один для массива - и экземпляры Point хранятся в виде строки в массиве.

Конструкторы Struct вызываются оператором new, но это не означает, что память выделяется. Вместо того, чтобы динамически размещать объект и возвращать ссылку на него, конструктор структуры просто возвращает само значение структуры (обычно во временном месте в стеке), и это значение затем копируется по мере необходимости.

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

Point a = new Point(10, 10);
Point b = a;
a.x = 20;
Console.WriteLine(b.x);

Если Point является классом, результат равен 20, потому что a и b ссылаются на один и тот же объект. Если Point является структурой, выходное значение равно 10, поскольку при присваивании a to b создается копия значения, и на эту копию не влияет последующее присвоение ax

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

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

Вот основное правило.

• Если все поля-члены являются типами значений, создайте структуру .

• Если какое-либо одно поле-член является ссылочным типом, создайте класс . Это связано с тем, что поле ссылочного типа в любом случае будет нуждаться в выделении кучи.

Exmaples

public struct MyPoint 
{
    public int X; // Value Type
    public int Y; // Value Type
}

public class MyPointWithName 
{
    public int X; // Value Type
    public int Y; // Value Type
    public string Name; // Reference Type
}

Первое: взаимодействие сценариев или когда вам нужно указать расположение памяти

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

Вам необходимо использовать "struct" в ситуациях, когда вы хотите явно указать макет памяти с помощью StructLayoutAttribute - обычно для PInvoke.

Редактировать: Комментарий указывает, что вы можете использовать класс или структуру со StructLayoutAttribute, и это, безусловно, верно. На практике вы обычно используете struct - она ​​распределяется в стеке, а не в куче, что имеет смысл, если вы просто передаете аргумент в вызов неуправляемого метода.

Я использую структуры для упаковки или распаковки любого двоичного формата связи. Это включает чтение или запись на диск, списки вершин DirectX, сетевые протоколы или работу с зашифрованными / сжатыми данными.

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

За исключением типов значений, которые используются непосредственно средой выполнения и различными другими для целей PInvoke, значения типов типов следует использовать только в 2 сценариях.

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

.NET поддерживает value typesи reference types(в Java вы можете определять только ссылочные типы). Экземпляры reference typesget выделяются в управляемой куче и собираются, когда на них нет ожидающих ссылок. Экземпляры value types, с другой стороны, выделяются в stack, и, следовательно, выделенная память восстанавливается, как только заканчивается их область действия. И, конечно же, value typesпередать по значению, иreference types по ссылке. Все примитивные типы данных C #, за исключением System.String, являются типами значений.

Когда использовать структуру над классом,

В C # structsесть value typesклассы reference types. Вы можете создавать типы значений в C #, используя enumключевое слово и structключевое слово. Использование value typeвместо a reference typeприведет к уменьшению количества объектов в управляемой куче, что приведет к меньшей нагрузке на сборщик мусора (GC), менее частым циклам GC и, следовательно, к повышению производительности. Впрочем, value typesесть и свои минусы тоже. Передача большого числа structопределенно обходится дороже, чем передача ссылки, это одна очевидная проблема. Другая проблема связана с накладными расходами boxing/unboxing. Если вам интересно, что boxing/unboxingозначает, перейдите по этим ссылкам для хорошего объясненияboxing иunboxing . Помимо производительности, бывают случаи, когда вам просто нужно, чтобы типы имели семантику значений, что было бы очень сложно (или уродливо) реализовать, еслиreference typesвсе, что у вас есть. Вы должны использовать value typesтолько, когда вам нужна семантика копирования или требуется автоматическая инициализация, обычно в arraysэтих типах.

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

public struct IntStruct {
    public int Value {get; set;}
}

Исключение следующих результатов приводит к 5 экземплярам структуры, хранящейся в памяти:

var struct1 = new IntStruct() { Value = 0 }; // original
var struct2 = struct1;  // A copy is made
var struct3 = struct2;  // A copy is made
var struct4 = struct3;  // A copy is made
var struct5 = struct4;  // A copy is made

// NOTE: A "copy" will occur when you pass a struct into a method parameter.
// To avoid the "copy", use the ref keyword.

// Although structs are designed to use less system resources
// than classes.  If used incorrectly, they could use significantly more.

Класс является ссылочным типом. Когда вы назначаете класс новой переменной, переменная содержит ссылку на исходный объект класса.

public class IntClass {
    public int Value {get; set;}
}

Исключение следующих результатов приводит только к одному экземпляру объекта класса в памяти.

var class1 = new IntClass() { Value = 0 };
var class2 = class1;  // A reference is made to class1
var class3 = class2;  // A reference is made to class1
var class4 = class3;  // A reference is made to class1
var class5 = class4;  // A reference is made to class1  

Struct s может увеличить вероятность ошибки кода. Если объект значения обрабатывается как изменяемый ссылочный объект, разработчик может удивиться, когда сделанные изменения будут неожиданно потеряны.

var struct1 = new IntStruct() { Value = 0 };
var struct2 = struct1;
struct2.Value = 1;
// At this point, a developer may be surprised when 
// struct1.Value is 0 and not 1

Я сделал небольшой тест с BenchmarkDotNet чтобы лучше понять преимущества "struct" в числах. Я тестирую циклический просмотр массива (или списка) структур (или классов). Создание этих массивов или списков выходит за рамки теста - ясно, что более тяжелый «класс» будет использовать больше памяти и будет включать GC.

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

PS Есть еще один тест для прохождения struct / class через стек вызовов https://stackoverflow.com/a/47864451/506147

BenchmarkDotNet=v0.10.8, OS=Windows 10 Redstone 2 (10.0.15063)
Processor=Intel Core i5-2500K CPU 3.30GHz (Sandy Bridge), ProcessorCount=4
Frequency=3233542 Hz, Resolution=309.2584 ns, Timer=TSC
  [Host] : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2101.1
  Clr    : Clr 4.0.30319.42000, 64bit RyuJIT-v4.7.2101.1
  Core   : .NET Core 4.6.25211.01, 64bit RyuJIT


          Method |  Job | Runtime |      Mean |     Error |    StdDev |       Min |       Max |    Median | Rank |  Gen 0 | Allocated |
---------------- |----- |-------- |----------:|----------:|----------:|----------:|----------:|----------:|-----:|-------:|----------:|
   TestListClass |  Clr |     Clr |  5.599 us | 0.0408 us | 0.0382 us |  5.561 us |  5.689 us |  5.583 us |    3 |      - |       0 B |
  TestArrayClass |  Clr |     Clr |  2.024 us | 0.0102 us | 0.0096 us |  2.011 us |  2.043 us |  2.022 us |    2 |      - |       0 B |
  TestListStruct |  Clr |     Clr |  8.427 us | 0.1983 us | 0.2204 us |  8.101 us |  9.007 us |  8.374 us |    5 |      - |       0 B |
 TestArrayStruct |  Clr |     Clr |  1.539 us | 0.0295 us | 0.0276 us |  1.502 us |  1.577 us |  1.537 us |    1 |      - |       0 B |
   TestLinqClass |  Clr |     Clr | 13.117 us | 0.1007 us | 0.0892 us | 13.007 us | 13.301 us | 13.089 us |    7 | 0.0153 |      80 B |
  TestLinqStruct |  Clr |     Clr | 28.676 us | 0.1837 us | 0.1534 us | 28.441 us | 28.957 us | 28.660 us |    9 |      - |      96 B |
   TestListClass | Core |    Core |  5.747 us | 0.1147 us | 0.1275 us |  5.567 us |  5.945 us |  5.756 us |    4 |      - |       0 B |
  TestArrayClass | Core |    Core |  2.023 us | 0.0299 us | 0.0279 us |  1.990 us |  2.069 us |  2.013 us |    2 |      - |       0 B |
  TestListStruct | Core |    Core |  8.753 us | 0.1659 us | 0.1910 us |  8.498 us |  9.110 us |  8.670 us |    6 |      - |       0 B |
 TestArrayStruct | Core |    Core |  1.552 us | 0.0307 us | 0.0377 us |  1.496 us |  1.618 us |  1.552 us |    1 |      - |       0 B |
   TestLinqClass | Core |    Core | 14.286 us | 0.2430 us | 0.2273 us | 13.956 us | 14.678 us | 14.313 us |    8 | 0.0153 |      72 B |
  TestLinqStruct | Core |    Core | 30.121 us | 0.5941 us | 0.5835 us | 28.928 us | 30.909 us | 30.153 us |   10 |      - |      88 B |

Код:

[RankColumn, MinColumn, MaxColumn, StdDevColumn, MedianColumn]
    [ClrJob, CoreJob]
    [HtmlExporter, MarkdownExporter]
    [MemoryDiagnoser]
    public class BenchmarkRef
    {
        public class C1
        {
            public string Text1;
            public string Text2;
            public string Text3;
        }

        public struct S1
        {
            public string Text1;
            public string Text2;
            public string Text3;
        }

        List<C1> testListClass = new List<C1>();
        List<S1> testListStruct = new List<S1>();
        C1[] testArrayClass;
        S1[] testArrayStruct;
        public BenchmarkRef()
        {
            for(int i=0;i<1000;i++)
            {
                testListClass.Add(new C1  { Text1= i.ToString(), Text2=null, Text3= i.ToString() });
                testListStruct.Add(new S1 { Text1 = i.ToString(), Text2 = null, Text3 = i.ToString() });
            }
            testArrayClass = testListClass.ToArray();
            testArrayStruct = testListStruct.ToArray();
        }

        [Benchmark]
        public int TestListClass()
        {
            var x = 0;
            foreach(var i in testListClass)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestArrayClass()
        {
            var x = 0;
            foreach (var i in testArrayClass)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestListStruct()
        {
            var x = 0;
            foreach (var i in testListStruct)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestArrayStruct()
        {
            var x = 0;
            foreach (var i in testArrayStruct)
            {
                x += i.Text1.Length + i.Text3.Length;
            }
            return x;
        }

        [Benchmark]
        public int TestLinqClass()
        {
            var x = testListClass.Select(i=> i.Text1.Length + i.Text3.Length).Sum();
            return x;
        }

        [Benchmark]
        public int TestLinqStruct()
        {
            var x = testListStruct.Select(i => i.Text1.Length + i.Text3.Length).Sum();
            return x;
        }
    }

Структурные типы в C # или других языках .net обычно используются для хранения вещей, которые должны вести себя как группы значений фиксированного размера. Полезный аспект типов структуры состоит в том, что поля экземпляра типа структуры могут быть изменены путем изменения места хранения, в котором он хранится, и никаким другим способом. Можно закодировать структуру таким образом, что единственный способ изменить любое поле - это создать совершенно новый экземпляр, а затем использовать присвоение структуры, чтобы изменить все поля цели, перезаписав их значениями из нового экземпляра, но если структура не предоставляет средств для создания экземпляра, где ее поля имеют значения не по умолчанию, все ее поля будут изменяемыми, если и если сама структура хранится в изменяемой папке.

Обратите внимание, что можно спроектировать тип структуры так, чтобы он по существу вел себя как тип класса, если структура содержит частное поле типа класса и перенаправляет своих собственных членов на объект обернутого класса. Например, a PersonCollectionможет предлагать свойства SortedByNameи SortedById, оба из которых содержат «неизменяемую» ссылку на PersonCollection(установленную в их конструкторе) и реализуют GetEnumerator, вызывая либо creator.GetNameSortedEnumeratoror, либо creator.GetIdSortedEnumerator. Такие структуры будут вести себя как ссылка на a PersonCollection, за исключением того, что их GetEnumeratorметоды будут связаны с различными методами в PersonCollection. Можно также иметь структуру для переноса части массива (например, можно определитьArrayRange<T> структуру, которая будет содержать T[]вызываемый Arr, intOffset и intLength, с индексированным свойством, которое для индекса idxв диапазоне от 0 до Length-1будет иметь доступ Arr[idx+Offset]). К сожалению, если fooэкземпляр такой структуры предназначен только для чтения, текущие версии компилятора не допускают таких операций, как, foo[3]+=4;потому что у них нет способа определить, будут ли такие операции пытаться записывать в поля foo.

Также возможно спроектировать структуру, которая будет вести себя как тип значения, который содержит коллекцию переменного размера (которая будет копироваться всякий раз, когда структура является структурой), но единственный способ выполнить эту работу - убедиться, что ни один объект, которому Структура содержит ссылку, которая будет когда-либо подвергаться воздействию всего, что может ее изменить. Например, можно иметь массивоподобную структуру, которая содержит закрытый массив, и чей индексированный метод «put» создает новый массив, содержимое которого аналогично содержимому оригинала, за исключением одного измененного элемента. К сожалению, может быть довольно сложно заставить такие структуры работать эффективно. Хотя бывают случаи, когда семантика структуры может быть удобной (например, возможность передавать массивоподобную коллекцию в подпрограмму, когда вызывающая сторона и вызываемая сторона знают, что внешний код не изменит коллекцию,

Нет, я не совсем согласен с правилами. Это хорошие рекомендации для оценки производительности и стандартизации, но не в свете возможностей.

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

В этом случае я использую классы для представления объектов реального мира в их большей форме, я использую структуры для представления более мелких объектов, которые имеют более точное использование. То, как вы это сказали, «более сплоченное целое». Ключевое слово является связным. Классы будут более объектно-ориентированными элементами, в то время как структуры могут иметь некоторые из этих характеристик, хотя и в меньшем масштабе. ИМО.

Я часто их использую в тегах Treeview и Listview, где очень быстро можно получить доступ к общим статическим атрибутам. Я всегда изо всех сил пытался получить эту информацию другим способом. Например, в моих приложениях базы данных я использую Treeview, где у меня есть таблицы, SP, функции или любые другие объекты. Я создаю и заполняю свою структуру, помещаю ее в тег, извлекаю, получаю данные выбора и так далее. Я бы не стал делать это с классом!

Я стараюсь держать их маленькими, использую их в единичных ситуациях и не допускаю их изменения. Целесообразно осознавать память, распределение и производительность. И тестирование так необходимо.

Мое правило

1, всегда используйте класс;

2. Если есть какие-либо проблемы с производительностью, я пытаюсь изменить класс для структурирования в зависимости от правил, упомянутых @IAbstract, а затем провожу тест, чтобы увидеть, могут ли эти изменения повысить производительность.

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

Классы и структуры (Руководство по программированию в C #)

МИФ № 1: СТРУКТЫ - ЛЕГКИЕ КЛАССЫ

Этот миф бывает разных форм. Некоторые люди считают, что типы значений не могут или не должны иметь методы или другое существенное поведение - их следует использовать как простые типы передачи данных, просто с открытыми полями или простыми свойствами. Тип DateTime является хорошим контрпримером к этому: имеет смысл для него быть типом значения с точки зрения фундаментальной единицы, такой как число или символ, и также имеет смысл иметь возможность выполнять вычисления на основе его ценность. Если посмотреть на вещи с другой стороны, типы передачи данных часто должны быть ссылочными типами, так как решение должно основываться на желаемом значении или семантике ссылочного типа, а не на простоте типа. Другие люди считают, что типы значений «легче», чем ссылочные типы с точки зрения производительности. Правда в том, что в некоторых случаях типы значений более производительны - им не требуется сборка мусора, если они не упакованы, не имеют накладных расходов на идентификацию типов и, например, не требуют разыменования. Но в других отношениях ссылочные типы более производительны - передача параметров, присвоение значений переменным, возвращение значений и аналогичные операции требуют только 4 или 8 байтов для копирования (в зависимости от того, используете ли вы 32-разрядный или 64-разрядный CLR ) вместо того, чтобы копировать все данные. Представьте, что ArrayList был каким-то «чистым» типом значения, и передача выражения ArrayList методу включала бы копирование всех его данных! Практически во всех случаях производительность не зависит от такого решения в любом случае. Узкие места почти никогда не бывают такими, какими вы их считаете, и прежде чем вы примете проектное решение, основанное на производительности, Вы должны измерить различные варианты. Стоит отметить, что сочетание двух убеждений тоже не работает. Не имеет значения, сколько методов имеет тип (будь то класс или структура) - память, взятая для каждого экземпляра, не затрагивается. (С точки зрения памяти, затрачиваемой на сам код, существует определенная стоимость, но это происходит один раз, а не для каждого экземпляра.)

МИФ № 2: СПРАВОЧНЫЕ ТИПЫ ЖИТЬ НА КАРТЕ; ЦЕННЫЕ ТИПЫ ЖИТЬ НА СТЕКЕ

Это часто вызвано ленью со стороны человека, повторяющего это. Первая часть верна - экземпляр ссылочного типа всегда создается в куче. Это вторая часть, которая вызывает проблемы. Как я уже отмечал, значение переменной живет везде, где она объявлена, поэтому, если у вас есть класс с переменной экземпляра типа int, значение этой переменной для любого данного объекта всегда будет там, где находятся остальные данные для объекта - в кучу. В стеке живут только локальные переменные (переменные, объявленные в методах) и параметры метода. В C # 2 и более поздних версиях даже некоторые локальные переменные в действительности не живут в стеке, как вы увидите, когда мы рассмотрим анонимные методы в главе 5. СООТВЕТСТВУЮТ ЛИ ЭТИ КОНЦЕПЦИИ СЕЙЧАС? Можно утверждать, что если вы пишете управляемый код, вы должны позволить среде выполнения беспокоиться о том, как лучше всего использовать память. Верно, спецификация языка не дает никаких гарантий относительно того, что и где живет; будущая среда выполнения может создать некоторые объекты в стеке, если знает, что это сойдет с рук, или компилятор C # может сгенерировать код, который вообще не использует стек. Следующий миф обычно является просто вопросом терминологии.

Миф № 3: объекты передаются по ссылке в C # по умолчанию

Это, наверное, самый распространенный миф. Опять же, люди, которые делают это заявление часто (хотя и не всегда), знают, как на самом деле ведет себя C #, но они не знают, что на самом деле означает «передача по ссылке». К сожалению, это сбивает с толку людей, которые знают, что это значит. Формальное определение передачи по ссылке является относительно сложным, включающим l-значения и похожую компьютерную терминологию, но важно то, что если вы передаете переменную по ссылке, вызываемый вами метод может изменить значение переменной вызывающей стороны изменив значение параметра. Теперь запомните, что значением переменной ссылочного типа является ссылка, а не сам объект. Вы можете изменить содержимое объекта, на который ссылается параметр, без передачи самого параметра по ссылке. Например,

void AppendHello(StringBuilder builder)
{
    builder.Append("hello");
}

Когда этот метод вызывается, значение параметра (ссылка на StringBuilder) передается по значению. Если бы вы изменили значение переменной построителя внутри метода - например, с помощью оператора builder = null; - это изменение не было бы замечено вызывающей стороной, вопреки мифу. Интересно отметить, что не только бит «по ссылке» мифа неточен, но и бит «объекты переданы». Сами объекты никогда не передаются ни по ссылке, ни по значению. Когда задействован ссылочный тип, либо переменная передается по ссылке, либо значение аргумента (ссылка) передается по значению. Помимо всего прочего, это отвечает на вопрос о том, что происходит, когда null используется в качестве аргумента по значению - если объекты передавались, это вызывало бы проблемы, поскольку не было бы объекта для передачи! Вместо, нулевая ссылка передается по значению так же, как и любая другая ссылка. Если это быстрое объяснение оставило вас в замешательстве, вы можете посмотреть мою статью «Передача параметров в C #» (http://mng.bz/otVt ), в котором речь пойдет гораздо подробнее. Эти мифы не единственные вокруг. Бокс и распаковка приходят из-за их значительного недопонимания, которое я постараюсь прояснить позже.

Ссылка: C # в глубине 3-е издание Джон Скит

Я думаю, что хорошее первое приближение - «никогда».

Я думаю, что хорошее второе приближение - «никогда».

Если вы отчаянно нуждаетесь в совершенстве, подумайте о них, но всегда измеряйте.

Я имел дело с именованным каналом Windows Communication Foundation [WCF] и заметил, что имеет смысл использовать Structs, чтобы гарантировать, что обмен данными имеет тип значения вместо ссылочного типа .

Структура C # является легкой альтернативой классу. Он может делать почти то же самое, что и класс, но дешевле использовать структуру, а не класс. Причина этого несколько техническая, но в итоге новые экземпляры класса помещаются в кучу, а новые экземпляры структур помещаются в стек. Кроме того, вы не имеете дело со ссылками на структуры, как с классами, но вместо этого вы работаете непосредственно с экземпляром структуры. Это также означает, что когда вы передаете структуру функции, она является значением, а не ссылкой. Подробнее об этом рассказывается в главе о параметрах функций.

Таким образом, вы должны использовать структуры, когда вы хотите представить более простые структуры данных, особенно если вы знаете, что будете создавать их экземпляры. Существует множество примеров в .NET Framework, где Microsoft использует структуры вместо классов, например структуру Point, Rectangle и Color.

Struct может быть использован для повышения производительности сборки мусора. Хотя вам обычно не нужно беспокоиться о производительности GC, есть сценарии, где это может быть убийственно. Как большие кэши в приложениях с низкой задержкой. Смотрите этот пост для примера:

http://00sharp.wordpress.com/2013/07/03/a-case-for-the-struct/

Типы структуры или значения могут использоваться в следующих сценариях:

1. Если вы хотите предотвратить сбор объекта при сборке мусора.
2. Если это простой тип и никакая функция-член не изменяет свои поля экземпляра
3. Если нет необходимости выводить из других типов или получать из других типов.

Вы можете узнать больше о типах значений и типах значений здесь по этой ссылке

Вкратце, используйте struct, если:

1- свойства / поля вашего объекта не нужно менять. Я имею в виду, вы просто хотите дать им начальное значение, а затем прочитать их.

2- свойства и поля в вашем объекте являются типом значения, и они не так велики.

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

Я редко использую структуру для вещей. Но это только я. Это зависит от того, нужен ли мне объект или нет.

Как указано в других ответах, я использую классы для объектов реального мира. У меня также есть мышление структур, которые используются для хранения небольших объемов данных.

Структуры во многом похожи на классы / объекты. Структура может содержать функции, члены и может быть унаследована. Но структуры в C # используются только для хранения данных . Структуры занимают меньше ОЗУ, чем классы, и их легче собирать сборщику мусора . Но когда вы используете функции в своей структуре, компилятор фактически принимает эту структуру очень похоже на класс / объект, поэтому, если вам нужно что-то с функциями, используйте класс / объект .