C#, почему структура потребности, если класс может покрыть его?

Обычно используйте класс.

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

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

Подробности см. в Викторина Рико Мариани о производительности + Ответы.

1, производительность. В некоторых случаях, используя структуры, мы получаем гораздо лучшую производительность.
2, неизменяемость данных. Изменив какое-либо свойство структуры, вы получите новую структуру. Это очень полезно в некоторых случаях
3, лучше контролировать представление в памяти. Мы можем точно определить, как структура расположена в памяти, и это позволяет нам быстро и эффективно сериализовать и десериализовать некоторые двоичные данные.

Структуры полезны просто потому, что они передаются по значению, что на самом деле может быть полезно в определенных алгоритмах. На самом деле это то, что классы НЕ МОГУТ делать.

struct ArrayPointer<T>
{
    public T[] Array;
    public int Offset;
}

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

• Struct vs Class в C #
• Советы по использованию C # Struct?
• Зачем нам нужны структуры? (C #)

Его практически необходимо использовать для взаимодействия с базовой структурой данных, используемой Win32 API. Я полагаю, что по этой причине может быть очень большая причина иметь его в .net.

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

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

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

Зачем использовать структуру , когда работает класс ? Потому что иногда класс не работает.

В дополнение к причинам производительности, упомянутым Ридом Копси (краткая версия: меньшее количество объектов, которые GC должен отслеживать, что позволяет GC лучше выполнять свою работу), есть одно место, где структуры должны быть Используется: P / Invoke для функций, которым требуются структуры по значению или элементы структуры.

Например, предположим, что вы хотите вызвать функцию CreateProcess () . Далее предположим, что вы хотите использовать структуру STARTUPINFOEX для параметра lpStartupInfo в CreateProcess () .

А что такое STARTUPINFOEX ? Это:

typedef struct _STARTUPINFOEX {
    STARTUPINFO                    StartupInfo;
    PPROC_THREAD_ATTRIBUTE_LIST    lpAttributeList;
} STARTUPINFOEX, *LPSTARTUPINFOEX;

Обратите внимание, что STARTUPINFOEX содержит STARTUPINFO в качестве своего первого члена. STARTUPINFO - это структура.

Поскольку классы являются ссылочными типами, если мы объявим соответствующий тип C # следующим образом:

[StructLayout(LayoutKind.Sequential)]
class STARTUPINFO { /* ... */ }

class STARTUPINFOEX { public STARTUPINFO StartupInfo; /* ... */ }

Соответствующий макет в памяти будет неправильным , поскольку STARTUPINFOEX.StartupInfo будет указатель (4 байта на платформах ILP32), НЕ структура (как требуется, размер 68 байтов на платформах ILP32).

Итак, для поддержки вызова произвольных функций, которые принимают произвольные структуры (в чем и заключается суть P / Invoke), необходимо одно из двух:

1. Полная поддержка типов значений. Это позволяет C # объявить тип значения для STARTUPINFO , который будет иметь правильный макет в памяти для маршалинга (т.е. поддержка struct , как в C #).

2. Некий альтернативный синтаксис в структурах P / Invokeable, который будет информировать маршаллер среды выполнения о том, что этот член должен быть представлен как тип значения, а не как указатель.

(2) - это работоспособное решение (и, возможно, использовалось в J / Direct в Visual J ++; я не помню), но, учитывая, что правильные типы значений более гибкие, включите ряд оптимизаций производительности, которые иначе невозможно и разумно использовать в сценариях P / Invoke, неудивительно, что C # поддерживает типы значений.