Коли слід використовувати stru, а не клас у C #? Моя концептуальна модель полягає в тому, що структури використовуються в часи, коли предмет є лише сукупністю типів значень . Спосіб логічно утримувати їх усіх разом у єдине ціле.

Я зіткнувся з цими правилами тут :

• Структура повинна представляти єдине значення.
• Структура повинна мати розмір пам'яті менше 16 байт.
• Структуру не слід змінювати після створення.

Чи працюють ці правила? Що означає семантично структура?

Джерело, на яке посилається ОП, має певну надійність ... але як щодо Microsoft - яка позиція щодо використання структури? Я шукав додаткового навчання у Microsoft , і ось що я знайшов:

Поміркуйте, як визначити структуру замість класу, якщо екземпляри типу невеликі і зазвичай недовговічні або зазвичай вбудовані в інші об'єкти.

Не визначайте структуру, якщо тип не має всіх наведених нижче характеристик:

1. Він логічно представляє єдине значення, подібне до примітивних типів (ціле число, подвійне і так далі).
2. Він має розмір екземпляра менше 16 байт.
3. Це незмінне.
4. Боксувати не доведеться часто.

Microsoft послідовно порушує ці правила

Гаразд, №2 і №3 все одно. Наш улюблений словник має дві внутрішні структури:

[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ніколи не передається як параметр поза класом Словник. Подальше дослідження показує, що для задоволення реалізації IEnumerable, словник використовує Enumeratorструктуру, яку він копіює щоразу, коли запитувач перераховує ... має сенс.
4. Внутрішній клас словника. Enumeratorє загальнодоступним, оскільки словник є численним і повинен мати однакову доступність до реалізації інтерфейсу IEnumerator - наприклад, Getter IEnumerator.

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

Що ми тут не бачимо, це будь-яка спроба чи доказ вимоги зберегти структури незмінні або підтримувати розмір екземпляра лише 16 байт або менше:

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

І ... 4. Обидва структури зберігають TKey і TValue, які всі ми знаємо, що цілком можуть бути еталонними типами (додана інформація про бонус)

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

Місткість: 312874
MemSize: 2660827 bytes
Завершено Розмір: 5ms
Загальний час заповнення: 889ms

Ємність : кількість елементів, доступних перед внутрішнім масивом, слід змінити розмір.

MemSize : визначається шляхом серіалізації словника в MemoryStream та отримання довжини байтів (достатньо точно для наших цілей).

Виконано зміни розміру : час, необхідний для зміни розміру внутрішнього масиву з 150862 елементів до 312874 елементів. Коли ви зрозумієте, що кожен елемент послідовно копіюється через Array.CopyTo(), це не надто пошарпано.

Загальний час для заповнення : зізнається, скасований через реєстрацію та OnResizeподію, яку я додав до джерела; однак все ще вражає заповнення цілих 300 к цілих чисел, змінюючи розмір 15 разів під час операції. Щось із цікавості, яким би був загальний час для заповнення, якби я вже знав ємність? 13 мс

Отже, що робити, якщо це Entryбув клас? Чи справді ці часи чи показники дійсно сильно різняться?

Місткість: 312874
MemSize: 2660827 байт
Завершено Розмір: 26ms
Загальний час для заповнення: 964ms

Очевидно, велика різниця полягає в зміні розміру. Будь-яка різниця, якщо Словник ініціалізований з 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: Structure Design . Коротко:

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

Якщо структура визначає конструктор за замовчуванням, коли масиви структури створюються, загальна мова виконання автоматично виконує конструктор за замовчуванням для кожного елемента масиву.

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

Це насправді досить просто, і ми запозичимо з трьох законів робототехніки Асімова :

1. Структура повинна бути безпечною у використанні
2. Структура повинна виконувати свою функцію ефективно, якщо тільки це не порушує правило №1
3. Під час використання конструкція повинна залишатися неушкодженою, якщо її руйнування не потрібно, щоб задовольнити правило №1

... що ми забираємо з цього : коротше кажучи, відповідальність за використання значень типів. Вони швидкі та ефективні, але здатні викликати багато несподіваних поведінки, якщо не підтримуються належним чином (тобто ненавмисні копії).

Всякий раз, коли вам не потрібен поліморфізм, потрібно мати значення семантики і хочете уникати розподілу купи та пов'язаного з цим сміття. Застереження, однак, полягає в тому, що структури (як завгодно великі) обходиться дорожче, ніж посилання на клас (як правило, одне машинне слово), тому класи можуть бути швидшими на практиці.

Я не згоден з правилами, наведеними в оригінальній публікації. Ось мої правила:

1) Ви використовуєте структури для продуктивності, зберігаючи їх у масивах. (див. також, коли відповіді на структури? )

2) Вам вони потрібні в коді, передаючи структуровані дані в / з C / C ++

3) Не використовуйте структури, якщо вони вам не потрібні:

• Вони поводяться відмінно від "нормальних об'єктів" ( типових типів ) під присвоєнням і при передачі в якості аргументів, що може призвести до несподіваної поведінки; це особливо небезпечно, якщо людина, яка дивиться на код, не знає, що має справу зі структурою.
• Вони не можуть бути успадковані.
• Передача структур як аргументів дорожче, ніж класи.

Використовуйте структуру, коли потрібно значення семантики значень на відміну від референтної семантики.

Редагувати

Не впевнений, чому люди заперечують це, але це справедливий момент, і це було зроблено ще до того, як оператор роз'яснив своє питання, і це найголовніша основна причина структури.

Якщо вам потрібна довідкова семантика, вам потрібен клас, а не структура.

Окрім відповіді "це значення", один конкретний сценарій використання структур - це коли ви знаєте, що у вас є набір даних, які викликають проблеми з вивезенням сміття, і у вас є багато об'єктів. Наприклад, великий список / масив екземплярів Person. Природна метафора тут - клас, але якщо у вас є велика кількість екземплярів довгоживої особи, вони можуть закінчитися засміченням GEN-2 і викликати зупинки GC. Якщо сценарій цього вимагає, одним із можливих підходів тут є використання масиву (не списку) структур Person , тобто Person[]. Тепер, замість того, щоб у GEN-2 були мільйони об'єктів, у вас є один фрагмент на LOH (я припускаю, що тут немає рядків тощо - тобто чисте значення без будь-яких посилань). Це дуже мало впливає на ГК.

Робота з цими даними є незручною, оскільки дані, ймовірно, занадто великі для структури, і ви не хочете весь час копіювати значення жиру. Однак доступ до нього безпосередньо в масиві не копіює структуру - вона є на місці (на відміну від індексатора списку, який копіює). Це означає багато роботи з індексами:

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

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

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

Знову ж таки, це на місці - ми не скопіювали значення.

У дуже конкретних сценаріях ця тактика може бути дуже успішною; однак, це досить просунутий scernario, який слід намагатися здійснити, лише якщо ви знаєте, що ви робите і чому. За замовчуванням тут буде клас.

Із специфікації мови 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 зберігаються в рядку в масиві.

Конструктори структур викликаються новим оператором, але це не означає, що виділяється пам'ять. Замість того, щоб динамічно розподіляти об'єкт і повертати посилання на нього, конструктор структури просто повертає значення структури (як правило, у тимчасове розташування на стеку), і це значення потім копіюється за необхідності.

За допомогою класів можна, щоб дві змінні посилалися на один і той самий об'єкт, і таким чином операції над однією змінною могли впливати на об'єкт, на який посилається інша змінна. У структурах кожна змінна має свою копію даних, і операції над однією з них не можуть впливати на іншу. Наприклад, результат, отриманий наступним фрагментом коду, залежить від того, точка є класом чи структурою.

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

Якщо Point - клас, вихід 20, тому що a і b посилаються на один і той же об'єкт. Якщо Point - структура, вихід 10 - тому, що присвоєння a b створює копію значення, і ця копія не впливає на подальше присвоєння ax

Попередній приклад висвітлює два обмеження конструкцій. По-перше, копіювання цілої структури зазвичай менш ефективно, ніж копіювання посилання на об'єкт, тому передача параметрів присвоєння та значення може бути дорожчою для структур, ніж для типів посилань. По-друге, крім параметрів ref і out, неможливо створити посилання на структури, що виключає їх використання в ряді ситуацій.

Структури хороші для атомного представлення даних, де зазначені дані можуть бути скопійовані кілька разів кодом. Клонування об'єкта взагалі дорожче, ніж копіювання структури, оскільки передбачає розподіл пам’яті, запуск конструктора та взаємодію / вивезення сміття, коли це зроблено з ним.

Ось основне правило.

• Якщо всі поля членів є типовими значеннями, створіть структуру .

• Якщо якесь одне поле члена є еталонним типом, створіть клас . Це тому, що поле референтного типу все одно потребуватиме виділення купи.

Приклади

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
}

По-перше: сценарії Interop або коли потрібно вказати макет пам'яті

По-друге: коли дані майже будь-якого розміру, як еталонний вказівник.

Потрібно використовувати "структура" в ситуаціях, коли ви хочете чітко вказати макет пам'яті за допомогою StructLayoutAttribute - як правило, для PInvoke.

Редагувати: коментар вказує, що ви можете використовувати клас або структуру з StructLayoutAttribute, і це, безумовно, правда. На практиці ти зазвичай використовуєш структуру - вона розподіляється на стеку проти купи, що має сенс, якщо ти просто передаєш аргумент на виклик некерованого методу.

Я використовую структури для упаковки або розпакування будь-якого формату двійкового зв'язку. Це включає читання або запис на диск, списки вершин DirectX, мережеві протоколи або обробку зашифрованих / стислих даних.

Три наведені вами рекомендації не були корисними для мене в цьому контексті. Коли мені потрібно виписати чотириста байт речей у Конкретному порядку, я визначу чотиристобайтну структуру, і я наповнити її будь-якими незв'язаними значеннями, які він повинен мати, і я збираюся налаштовувати його будь-яким способом має найбільш сенс на той час. (Гаразд, чотириста байт було б досить дивно ... але тоді, коли я писав файли Excel для життя, я мав справу зі структурами розміром до сорока байтів у всьому, тому що настільки великі деякі записи BIFF.)

За винятком значень типів, які використовуються безпосередньо під час виконання та різними іншими цілями для цілей PInvoke, вам слід використовувати вартієтипи лише у двох сценаріях.

1. Коли вам потрібна семантика копіювання.
2. Коли вам потрібна автоматична ініціалізація, як правило, в масивах цих типів.

.NET підтримує value typesта reference types(у Java ви можете визначити лише типи посилань). Екземпляри reference typesвиділяються в керовану купу і збираються сміття, коли на них немає видатних посилань. Екземпляри value types, з іншого боку, виділяються в stack, і, отже, виділена пам’ять відновлюється, як тільки їх область закінчується. І звичайно, value typesпроходити як за значенням, так і reference typesза посиланням. Усі примітивні типи даних C #, за винятком System.String, є типовими значеннями.

Коли використовувати структура над класом,

У C #, structsє value types, класи є reference types. Ви можете створити типи значень у C #, використовуючи enumключове слово та structключове слово. Використання value typeзамість 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, щоб краще зрозуміти «структура» вигоди в числах. Я тестую циклічний перегляд через масив (або список) структур (або класів). Створення цих масивів чи списків виходить за межі еталону - зрозуміло, що "клас" важчий, задіяє більше пам'яті, і він буде залучати GC.

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

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

Зауважте, що можна сконструювати тип структури так, щоб він по суті поводився як тип класу, якщо структура містить приватне поле типу класу та перенаправляє власні члени до об’єкта загорнутого класу. Наприклад, PersonCollectionможе запропонувати властивості, SortedByNameі SortedByIdобидва вони містять "незмінне" посилання на PersonCollection(встановлений у їх конструкторі) та реалізують GetEnumerator, викликаючи або creator.GetNameSortedEnumeratorабо creator.GetIdSortedEnumerator. Такі структури будуть поводитись так само, як посилання на a PersonCollection, за винятком того, що їхні GetEnumeratorметоди будуть пов'язані з різними методами в PersonCollection. Можна також мати структуру, яка обгортає частину масиву (наприклад, можна визначити ArrayRange<T>структуру, яка міститиме T[]виклик Arr, int Offsetта intLength, З індексним майна , які за індексом idxв діапазоні від 0 до Length-1, буде доступ Arr[idx+Offset]). На жаль, якщо fooекземпляр такої структури є лише для читання, поточні версії компілятора не дозволять виконувати такі операції, як foo[3]+=4;тому, що вони не мають змоги визначити, чи намагалися б такі операції записувати в поля foo.

Можна також спроектувати структуру, яка поводиться як тип значення, який містить колекцію змінного розміру (яка, здається, буде скопійована кожного разу, коли структура), але єдиний спосіб зробити цю роботу - забезпечити відсутність об'єкта, до якого Структура посилань коли-небудь буде піддаватися чому-небудь, що може його мутувати. Наприклад, може бути структура, схожа на масив, яка містить приватний масив, і індексований метод "put" створює новий масив, вміст якого схожий на оригінальний, за винятком одного зміненого елемента. На жаль, зробити так, щоб такі структури були ефективними, може бути дещо складно. Хоча буває, що семантика структури може бути зручною (наприклад, можливість передавати колекцію, схожу на масив, у звичайну програму, причому абонент і абонент обидва знають, що зовнішній код не змінює колекцію,

Ні - я не повністю згоден з правилами. Вони є гарними рекомендаціями, які слід враховувати з ефективністю та стандартизацією, але не з огляду на можливості.

Як ви бачите у відповідях, існує багато творчих способів їх використання. Отже, ці вказівки повинні бути саме такими, завжди заради продуктивності та ефективності.

У цьому випадку я використовую класи, щоб представити об'єкти реального світу в їх більшій формі, я використовую структури для представлення менших об'єктів, які мають більш точне використання. Як ви це сказали, "більш згуртоване ціле". Ключове слово є згуртованим. Класи будуть більш об'єктно-орієнтованими елементами, тоді як структури можуть мати деякі з цих характеристик, хоча в меншому масштабі. ІМО.

Я їх багато використовую в тегах Treeview і Listview, де до загальних статичних атрибутів можна отримати доступ дуже швидко. Я завжди намагався отримати цю інформацію іншим способом. Наприклад, у своїх додатках для баз даних я використовую Treeview, де у мене є таблиці, SP-адреси, функції або будь-які інші об'єкти. Я створюю та заповнюю свою структуру, вкладаю її в тег, витягую її, отримую дані про вибір і так далі. Я б не робив цього з класом!

Я намагаюся тримати їх невеликими, використовую їх в окремих ситуаціях і не дозволяю їм змінюватися. Доцільно бути в курсі пам’яті, розподілу та продуктивності. І тестування так необхідне.

Моє правило таке

1, Завжди використовувати клас;

2, Якщо є якісь проблеми продуктивності, я намагаюся змінити деякий клас на структуру залежно від правил, про які згадується @IAbrief, а потім зробити тест, щоб побачити, чи можуть ці зміни покращити продуктивність.

Клас - еталонний тип. Коли створюється об’єкт класу, змінна, якій призначений об'єкт, містить лише посилання на цю пам'ять. Коли посилання на об'єкт присвоюється новій змінній, нова змінна відноситься до вихідного об'єкта. Зміни, внесені через одну змінну, відображаються в іншій змінній, оскільки вони обоє посилаються на одні і ті ж дані. Структура - це тип значення. Коли структура створена, змінна, якій призначається структура, містить фактичні дані структури. Коли структура присвоюється новій змінній, вона копіюється. Нова змінна та оригінальна змінна тому містять дві окремі копії одних і тих же даних. Зміни, внесені до однієї копії, не впливають на іншу. Взагалі класи використовуються для моделювання більш складної поведінки або даних, які призначені для зміни після створення об’єкта класу.

Класи та структури (Посібник з програмування 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 в рамках методу - наприклад, з оператором builder = null; - то зміни, які викликає користувач, не побачать, всупереч міфу. Цікаво зауважити, що міф "посилання" не лише неточний, але й біт "об'єктів передається". Самі об’єкти ніколи не передаються ні за посиланням, ні за значенням. Коли задіяний тип посилання, або змінна передається за посиланням, або значення аргументу (посилання) передається за значенням. Окрім нічого іншого, це відповідає на питання, що відбувається, коли null використовується як аргумент за значенням - якщо об’єкти передавались навколо, це спричинило б проблеми, оскільки не було б об’єкта, який потрібно передавати! Натомість нульове посилання передається за значенням так само, як і будь-яке інше посилання. Якщо це швидке пояснення залишило вас збентеженим, ви можете подивитися на мою статтю "Параметр, що проходить у C #" (http://mng.bz/otVt ), де йдеться про набагато детальніше. Ці міфи не єдині навколо. Бокс і розблокування приходять за свою справедливу частку нерозуміння, яку я спробую вияснити наступним.

Довідка: C # у глибині 3-го видання Джона Скіта

Я думаю, гарне перше наближення - це "ніколи".

Я думаю, що гарне друге наближення - "ніколи".

Якщо ви відчайдушно відчуваєте парфуми, розгляньте їх, але тоді завжди міряйте.

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

Структура C # - це легка альтернатива класу. Це може робити майже те саме, що і клас, але використовувати структуру, а не клас, менш «дорого». Причина цього трохи технічна, але, підводячи підсумок, нові екземпляри класу розміщуються на купі, де на стек розміщуються новоінстанційні структури. Крім того, ви не маєте справу з посиланнями на структури, як з класами, а натомість ви працюєте безпосередньо з екземпляром структури. Це також означає, що коли ви передаєте структуру функції, вона є за значенням, а не як еталон. Про це докладніше в главі про параметри функції.

Отже, вам слід використовувати структури, коли ви хочете представляти більш прості структури даних, і особливо якщо ви знаєте, що ви будете інстанціювати їх багато. У структурі .NET є багато прикладів, де Microsoft використовує структури замість класів, наприклад, Point, Rectangle та Color structure.

Структуру можна використовувати для поліпшення продуктивності вивезення сміття. Хоча зазвичай не потрібно турбуватися про продуктивність GC, існують сценарії, коли це може бути вбивцею. Як і великі кеші в додатках із низькою затримкою. Дивіться приклад для цієї публікації:

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

Типи структури або значення можуть використовуватися в наступних сценаріях -

1. Якщо ви хочете не допустити збирання об’єкта шляхом вивезення сміття.
2. Якщо це простий тип, і жодна функція-член не змінює поля примірника
3. Якщо немає необхідності виходити з інших типів або бути похідним до інших типів.

Ви можете дізнатися більше про типи значень та типи значень тут за цим посиланням

Коротко, скористайтеся структурою, якщо:

1- ваші властивості / поля об'єкта не потрібно змінювати. Я маю на увазі, що ви просто хочете дати їм початкове значення, а потім прочитати їх.

2- властивості та поля у вашому об’єкті є типом значень, і вони не такі великі.

Якщо це так, ви можете скористатися структурами для кращої продуктивності та оптимізованого розподілу пам'яті, оскільки вони використовують лише стеки, а не стеки та купи (у класах)

Я рідко використовую структуру для речей. Але це тільки я. Це залежить від того, чи потрібен мені предмет, який буде нульовим, чи ні.

Як зазначено в інших відповідях, я використовую класи для об'єктів реального світу. Я також маю на увазі, що структури використовуються для зберігання невеликої кількості даних.

Структури подібні до класів / об'єктів. Структура може містити функції, члени і може передаватися у спадок. Але структури в C # використовуються тільки для зберігання даних . Структури займають менше оперативної пам’яті, ніж класи, і збирання сміття простіше збирати . Але коли ви використовуєте функції у своїй структурі, компілятор насправді сприймає цю структуру дуже аналогічно класу / об’єкту, тож якщо ви хочете чогось із функціями, тоді використовуйте клас / об’єкт .