Quando dovresti usare struct e non class in C #? Il mio modello concettuale è che le strutture vengono utilizzate nei momenti in cui l'oggetto è semplicemente una raccolta di tipi di valore . Un modo per tenerli logicamente tutti insieme in un insieme coeso.

Mi sono imbattuto in queste regole qui :

• Una struttura dovrebbe rappresentare un singolo valore.
• Una struttura dovrebbe avere un footprint di memoria inferiore a 16 byte.
• Una struttura non deve essere modificata dopo la creazione.

Queste regole funzionano? Cosa vuol dire semanticamente una struttura?

La fonte a cui fa riferimento l'OP ha una certa credibilità ... ma per quanto riguarda Microsoft: qual è la posizione sull'utilizzo della struttura? Ho cercato un po 'di apprendimento extra da Microsoft , ed ecco cosa ho trovato:

Prendi in considerazione la definizione di una struttura anziché di una classe se le istanze del tipo sono piccole e comunemente di breve durata o sono comunemente incorporate in altri oggetti.

Non definire una struttura a meno che il tipo non abbia tutte le seguenti caratteristiche:

1. Rappresenta logicamente un singolo valore, simile ai tipi primitivi (intero, doppio e così via).
2. Ha una dimensione dell'istanza inferiore a 16 byte.
3. È immutabile
4. Non dovrà essere inscatolato frequentemente.

Microsoft viola costantemente tali regole

Va bene, # 2 e # 3 comunque. Il nostro amato dizionario ha 2 strutture interne:

[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
}

* Fonte di riferimento

La fonte di "JonnyCantCode.com" ha ottenuto 3 su 4 - abbastanza perdonabile poiché il numero 4 probabilmente non sarebbe un problema. Se ti ritrovi a boxare una struttura, ripensa alla tua architettura.

Vediamo perché Microsoft dovrebbe usare queste strutture:

1. Ogni struttura Entrye Enumeratorrappresenta singoli valori.
2. Velocità
3. Entrynon viene mai passato come parametro al di fuori della classe del dizionario. Ulteriori ricerche dimostrano che, al fine di soddisfare l'implementazione di IEnumerable, Dictionary utilizza la Enumeratorstruttura che copia ogni volta che viene richiesto un enumeratore ... ha senso.
4. Interno alla classe del dizionario. Enumeratorè pubblico perché Dizionario è enumerabile e deve avere uguale accessibilità all'implementazione dell'interfaccia IEnumerator, ad esempio IEnumerator getter.

Aggiornamento : inoltre, rendersi conto che quando una struttura implementa un'interfaccia - come fa Enumerator - e viene lanciata su quel tipo implementato, la struttura diventa un tipo di riferimento e viene spostata nell'heap. Interno alla classe Dictionary, Enumerator è ancora un tipo di valore. Tuttavia, non appena viene chiamato un metodo GetEnumerator(), IEnumeratorviene restituito un tipo di riferimento .

Quello che non vediamo qui è alcun tentativo o prova del requisito per mantenere immutabili le strutture o mantenere una dimensione dell'istanza di soli 16 byte o meno:

1. Nulla nelle strutture sopra è dichiarato readonly- non immutabile
2. Le dimensioni di queste strutture potrebbero superare i 16 byte
3. Entryha una durata indeterminata (da Add(), per Remove(), Clear()o raccolta dei rifiuti);

E ... 4. Entrambe le strutture memorizzano TKey e TValue, che sappiamo tutti essere abbastanza capaci di essere tipi di riferimento (informazioni aggiuntive sul bonus)

Nonostante i tasti tratteggiati, i dizionari sono in parte veloci in quanto l'istanza di una struttura è più rapida di un tipo di riferimento. Qui, ho un Dictionary<int, int>che memorizza 300.000 numeri interi casuali con chiavi incrementalmente sequenzialmente.

Capacità: 312874 Dimensione
memoria: 2660827 byte
Ridimensionamento completato: 5 ms
Tempo totale di riempimento: 889 ms

Capacità : numero di elementi disponibili prima che l'array interno debba essere ridimensionato.

MemSize : determinato serializzando il dizionario in un MemoryStream e ottenendo una lunghezza in byte (abbastanza accurata per i nostri scopi).

Ridimensionamento completato : il tempo necessario per ridimensionare l'array interno da 150862 elementi a 312874 elementi. Quando pensi che ogni elemento sia copiato in sequenza via Array.CopyTo(), non è troppo malandato.

Tempo totale da riempire : certamente distorto a causa della registrazione e di un OnResizeevento che ho aggiunto alla fonte; tuttavia, è comunque impressionante riempire 300k interi mentre si ridimensiona 15 volte durante l'operazione. Solo per curiosità, quale sarebbe il tempo totale da riempire se conoscessi già la capacità? 13ms

Quindi, ora, se Entryfosse una classe? Questi tempi o metriche differirebbero così tanto?

Capacità: 312874 Dimensione
memoria: 2660827 byte
Ridimensionamento completato: 26 ms
Tempo totale di riempimento: 964 ms

Ovviamente, la grande differenza sta nel ridimensionamento. Qualche differenza se il dizionario è inizializzato con la capacità? Non abbastanza per preoccuparsi di ... 12ms .

Quello che succede è che, poiché Entryè una struttura, non richiede l'inizializzazione come un tipo di riferimento. Questa è sia la bellezza che la rovina del tipo di valore. Per utilizzare Entrycome tipo di riferimento, ho dovuto inserire il seguente codice:

/*
 *  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( );
}
/*  *********************************************** */  

Il motivo per cui ho dovuto inizializzare ciascun elemento dell'array Entrycome tipo di riferimento è disponibile in MSDN: Structure Design . In breve:

Non fornire un costruttore predefinito per una struttura.

Se una struttura definisce un costruttore predefinito, quando vengono create le matrici della struttura, Common Language Runtime esegue automaticamente il costruttore predefinito su ciascun elemento dell'array.

Alcuni compilatori, come il compilatore C #, non consentono alle strutture di avere costruttori predefiniti.

In realtà è abbastanza semplice e si prenderà in prestito dal di Asimov Tre leggi della robotica :

1. La struttura deve essere sicura da usare
2. La struttura deve svolgere la sua funzione in modo efficiente, a meno che ciò non violi la regola n. 1
3. La struttura deve rimanere intatta durante l'uso a meno che non sia richiesta la sua distruzione per soddisfare la regola n. 1

... cosa ci toglie da questo : in breve, sii responsabile dell'uso dei tipi di valore. Sono veloci ed efficienti, ma hanno la capacità di causare molti comportamenti imprevisti se non adeguatamente mantenuti (ovvero copie involontarie).

Ogni volta che si:

1. non ho bisogno del polimorfismo,
2. desidera una semantica di valore e
3. desidera evitare l'allocazione dell'heap e l'overhead della garbage collection associata.

L'avvertenza, tuttavia, è che le strutture (arbitrariamente grandi) sono più costose da spostare rispetto ai riferimenti di classe (di solito una parola macchina), quindi le classi potrebbero finire per essere più veloci nella pratica.

Non sono d'accordo con le regole indicate nel post originale. Ecco le mie regole:

1) Le strutture vengono utilizzate per le prestazioni se archiviate in array. (vedi anche Quando sono le strutture la risposta? )

2) Ne hai bisogno nel codice che passa i dati strutturati a / da C / C ++

3) Non utilizzare le strutture a meno che non siano necessarie:

• Si comportano in modo diverso dagli "oggetti normali" ( tipi di riferimento ) durante l'assegnazione e quando passano come argomenti, il che può portare a comportamenti imprevisti; questo è particolarmente pericoloso se la persona che guarda il codice non sa di avere a che fare con una struttura.
• Non possono essere ereditati.
• Passare le strutture come argomenti è più costoso delle classi.

Utilizzare uno struct quando si desidera la semantica di valore anziché la semantica di riferimento.

modificare

Non sono sicuro del motivo per cui la gente sta effettuando il downvoting di questo, ma questo è un punto valido, ed è stato fatto prima che l'operazione chiarisse la sua domanda, ed è la ragione fondamentale di base per una struttura.

Se hai bisogno di una semantica di riferimento, hai bisogno di una classe e non di una struttura.

Oltre alla risposta "è un valore", uno scenario specifico per l'utilizzo delle strutture è quando sai di avere un set di dati che causa problemi di garbage collection e di avere molti oggetti. Ad esempio, un ampio elenco / array di istanze Person. La metafora naturale qui è una classe, ma se hai un gran numero di istanze Person di lunga durata, possono finire per intasare GEN-2 e causare bancarelle GC. Se lo scenario lo giustifica, un potenziale approccio qui è quello di utilizzare un array (non un elenco) di strutture Person , ad es Person[]. Ora, invece di avere milioni di oggetti in GEN-2, hai un singolo pezzo sul LOH (suppongo che non ci siano stringhe ecc. Qui - cioè un valore puro senza riferimenti). Questo ha un impatto GC minimo.

Lavorare con questi dati è imbarazzante, poiché i dati sono probabilmente sovradimensionati per una struttura e non si desidera copiare sempre valori di grasso. Tuttavia, accedervi direttamente in un array non copia la struttura - è sul posto (contrariamente a un indicizzatore di elenco, che copia). Ciò significa molto lavoro con gli indici:

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

Si noti che mantenere immutabili i valori stessi aiuterà qui. Per una logica più complessa, utilizzare un metodo con un parametro by-ref:

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

Ancora una volta, questo è a posto - non abbiamo copiato il valore.

In scenari molto specifici, questa tattica può avere molto successo; tuttavia, è uno scernario abbastanza avanzato che dovrebbe essere tentato solo se sai cosa stai facendo e perché. L'impostazione predefinita qui sarebbe una classe.

Dalle specifiche del linguaggio C # :

1.7 Strutture

Come le classi, le strutture sono strutture di dati che possono contenere membri di dati e membri di funzioni, ma a differenza delle classi, le strutture sono tipi di valore e non richiedono allocazione di heap. Una variabile di un tipo struct memorizza direttamente i dati della struttura, mentre una variabile di un tipo di classe memorizza un riferimento a un oggetto allocato dinamicamente. I tipi di struttura non supportano l'ereditarietà specificata dall'utente e tutti i tipi di struttura ereditano implicitamente dall'oggetto tipo.

Le strutture sono particolarmente utili per le piccole strutture di dati con semantica di valore. Numeri complessi, punti in un sistema di coordinate o coppie chiave-valore in un dizionario sono tutti buoni esempi di strutture. L'uso di strutture anziché di classi per strutture di dati di piccole dimensioni può fare una grande differenza nel numero di allocazioni di memoria eseguite da un'applicazione. Ad esempio, il seguente programma crea e inizializza un array di 100 punti. Con Point implementato come classe, vengono istanziati 101 oggetti separati, uno per l'array e uno per i 100 elementi.

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);
   }
}

Un'alternativa è rendere Point una struttura.

struct Point
{
   public int x, y;

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

Ora, viene istanziato solo un oggetto, quello per l'array, e le istanze Point vengono archiviate in linea nell'array.

I costruttori di Struct sono richiamati con il nuovo operatore, ma ciò non implica che la memoria sia allocata. Invece di allocare in modo dinamico un oggetto e restituire un riferimento ad esso, un costruttore di strutture restituisce semplicemente il valore di struttura stesso (in genere in una posizione temporanea sullo stack) e questo valore viene quindi copiato come necessario.

Con le classi, è possibile che due variabili facciano riferimento allo stesso oggetto e quindi che le operazioni su una variabile influenzino l'oggetto a cui fa riferimento l'altra variabile. Con le strutture, le variabili hanno ciascuna una propria copia dei dati e non è possibile che le operazioni su uno influiscano sull'altro. Ad esempio, l'output prodotto dal seguente frammento di codice dipende dal fatto che Point sia una classe o una struttura.

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

Se Point è una classe, l'output è 20 perché aeb fanno riferimento allo stesso oggetto. Se Point è una struttura, l'output è 10 perché l'assegnazione di a a b crea una copia del valore e questa copia non è influenzata dalla successiva assegnazione a ax

L'esempio precedente evidenzia due dei limiti delle strutture. Innanzitutto, la copia di un'intera struttura è in genere meno efficiente della copia di un riferimento a un oggetto, quindi il passaggio di parametri di assegnazione e valore può essere più costoso con le strutture che con i tipi di riferimento. In secondo luogo, ad eccezione dei parametri ref e out, non è possibile creare riferimenti a strutture, il che ne esclude l'utilizzo in diverse situazioni.

Le strutture sono utili per la rappresentazione atomica di dati, in cui tali dati possono essere copiati più volte dal codice. La clonazione di un oggetto è in genere più costosa della copia di una struttura, poiché comporta l'allocazione della memoria, l'esecuzione del costruttore e la deallocazione / garbage collection al termine.

Ecco una regola di base.

• Se tutti i campi membro sono tipi di valore, creare una struttura .

• Se un campo membro è un tipo di riferimento, creare una classe . Questo perché il campo del tipo di riferimento richiederà comunque l'allocazione dell'heap.

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
}

Primo: scenari di interoperabilità o quando è necessario specificare il layout di memoria

Secondo: quando i dati hanno quasi le stesse dimensioni di un puntatore di riferimento comunque.

È necessario utilizzare una "struttura" nelle situazioni in cui si desidera specificare esplicitamente il layout di memoria utilizzando StructLayoutAttribute , in genere per PInvoke.

Modifica: il commento sottolinea che è possibile utilizzare class o struct con StructLayoutAttribute e questo è certamente vero. In pratica, in genere si utilizza una struttura: è allocata nello stack rispetto all'heap, il che ha senso se si sta semplicemente passando un argomento a una chiamata di metodo non gestita.

Uso le strutture per impacchettare o disimballare qualsiasi tipo di formato di comunicazione binaria. Ciò include la lettura o la scrittura su disco, gli elenchi di vertici DirectX, i protocolli di rete o la gestione di dati crittografati / compressi.

Le tre linee guida che elenchi non mi sono state utili in questo contesto. Quando avrò bisogno di scrivere quattrocento byte di roba in un Ordine particolare, definirò una struttura di quattrocento byte e la riempirò con tutti i valori non correlati che dovrebbe avere, e sto andando per impostarlo in qualsiasi modo abbia più senso in quel momento. (Va bene, quattrocento byte sarebbero piuttosto strani-- ma quando stavo scrivendo file Excel per vivere, avevo a che fare con strutture fino a una quarantina di byte dappertutto, perché è grande quanto sono alcuni dei record BIFF.)

Con l'eccezione dei tipi di valore utilizzati direttamente dal runtime e vari altri scopi di PInvoke, è necessario utilizzare i tipi di valore in 2 scenari.

1. Quando hai bisogno della semantica della copia.
2. Quando è necessaria l'inizializzazione automatica, normalmente in array di questi tipi.

.NET supporta value typese reference types(in Java, è possibile definire solo i tipi di riferimento). Le istanze reference typesvengono allocate nell'heap gestito e vengono raccolte in modo inutile quando non vi sono riferimenti in sospeso a esse. value typesD'altra parte, le istanze di sono allocate nella stackmemoria, e quindi la memoria allocata viene recuperata non appena termina il loro ambito. E, naturalmente, fatti value typespassare per valore e reference typesper riferimento. Tutti i tipi di dati primitivi C #, ad eccezione di System.String, sono tipi di valore.

Quando usare struct over class,

In C #, structssono value types, le classi sono reference types. Puoi creare tipi di valore, in C #, usando la enumparola chiave e la structparola chiave. L'uso di al value typeposto di a reference typecomporterà un minor numero di oggetti sull'heap gestito, con conseguente minor carico sul Garbage Collector (GC), cicli GC meno frequenti e conseguentemente migliori prestazioni. Tuttavia, value typeshanno anche i loro lati negativi. Passare intorno a un grosso structè decisamente più costoso di passare un riferimento, questo è un problema evidente. L'altro problema è il sovraccarico associato boxing/unboxing. Nel caso ti stia chiedendo cosa boxing/unboxingsignifichi, segui questi link per una buona spiegazione su boxingeunboxing. A parte le prestazioni, ci sono momenti in cui hai semplicemente bisogno di tipi per avere una semantica di valore, il che sarebbe molto difficile (o brutto) da implementare se reference typestutto ciò che hai. È consigliabile utilizzare value typessolo, quando è necessario copiare la semantica o è necessaria l'inizializzazione automatica, normalmente in arraysquesti tipi.

Una struttura è un tipo di valore. Se si assegna una struttura a una nuova variabile, la nuova variabile conterrà una copia dell'originale.

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

L'esecuzione dei seguenti risultati in 5 istanze della struttura archiviata in memoria:

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.

Una classe è un tipo di riferimento. Quando si assegna una classe a una nuova variabile, la variabile contiene un riferimento all'oggetto classe originale.

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

L'esecuzione di quanto segue comporta solo un'istanza dell'oggetto di classe in memoria.

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 può aumentare la probabilità di un errore del codice. Se un oggetto valore viene trattato come un oggetto di riferimento mutabile, uno sviluppatore potrebbe rimanere sorpreso quando le modifiche apportate vengono perse inaspettatamente.

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

Ho fatto un piccolo benchmark con BenchmarkDotNet per comprendere meglio i vantaggi della "struttura" numerica. Sto testando il looping attraverso array (o elenco) di strutture (o classi). La creazione di tali array o elenchi non rientra nell'ambito del benchmark: è chiaro che la "classe" più pesante utilizzerà più memoria e coinvolgerà GC.

Quindi la conclusione è: state attenti con LINQ e boxing / unboxing di strutture nascoste e l'utilizzo di strutture per le microottimizzazioni è strettamente correlato alle matrici.

PS Un altro punto di riferimento sul passaggio di struct / class attraverso lo stack di chiamate è lì 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 |

Codice:

[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;
        }
    }

I tipi di struttura in C # o altri linguaggi .net vengono generalmente utilizzati per contenere elementi che dovrebbero comportarsi come gruppi di valori di dimensioni fisse. Un aspetto utile dei tipi di struttura è che i campi di un'istanza di tipo struttura possono essere modificati modificando la posizione di archiviazione in cui si trova e in nessun altro modo. È possibile codificare una struttura in modo tale che l'unico modo per mutare qualsiasi campo sia costruire un'istanza completamente nuova e quindi utilizzare un'assegnazione struct per mutare tutti i campi del target sovrascrivendoli con i valori della nuova istanza, ma a meno che una struttura non fornisca alcun mezzo per creare un'istanza in cui i suoi campi abbiano valori non predefiniti, tutti i suoi campi saranno mutabili se e se la struttura stessa è memorizzata in una posizione mutabile.

Si noti che è possibile progettare un tipo di struttura in modo che si comporti essenzialmente come un tipo di classe, se la struttura contiene un campo di tipo di classe privato e reindirizza i propri membri a quello dell'oggetto di classe avvolto. Ad esempio, a PersonCollectionpotrebbe offrire proprietà SortedByNamee SortedById, entrambe le quali contengono un riferimento "immutabile" a un PersonCollection(impostato nel loro costruttore) e implementano GetEnumeratorchiamando creator.GetNameSortedEnumeratoro creator.GetIdSortedEnumerator. Tali strutture si comporterebbero in modo molto simile a un riferimento a PersonCollection, tranne per il fatto che i loro GetEnumeratormetodi sarebbero legati a metodi diversi in PersonCollection. Si potrebbe anche avere una struttura che avvolge una porzione di un array (ad esempio si potrebbe definire una ArrayRange<T>struttura che potrebbe contenere un T[]chiamato Arr, un int Offsete un intLength, con una proprietà indicizzata alla quale, per un indice idxnell'intervallo da 0 a Length-1, accederebbe Arr[idx+Offset]). Sfortunatamente, se si footratta di un'istanza di sola lettura di tale struttura, le attuali versioni del compilatore non consentiranno operazioni come foo[3]+=4;perché non hanno modo di determinare se tali operazioni tenterebbero di scrivere nei campi di foo.

È anche possibile progettare una struttura in modo da comportarsi come un tipo di valore che contiene una raccolta di dimensioni variabili (che sembrerà essere copiata ogni volta che la struttura è) ma l'unico modo per farlo funziona è quello di garantire che nessun oggetto a cui struct detiene un riferimento sarà mai esposto a qualsiasi cosa possa mutarlo. Ad esempio, si potrebbe avere una struttura simile a un array che contiene un array privato e il cui metodo "put" indicizzato crea un nuovo array il cui contenuto è simile a quello dell'originale tranne un elemento modificato. Sfortunatamente, può essere in qualche modo difficile far funzionare in modo efficiente tali strutture. Mentre ci sono momenti in cui la semantica della struttura può essere conveniente (ad esempio essere in grado di passare una raccolta simile ad un array a una routine, con il chiamante e il chiamante entrambi consapevoli che il codice esterno non modificherà la raccolta,

Nah - Non sono completamente d'accordo con le regole. Sono buone linee guida da considerare con prestazioni e standardizzazione, ma non alla luce delle possibilità.

Come puoi vedere nelle risposte, ci sono molti modi creativi per usarli. Quindi, queste linee guida devono essere proprio questo, sempre per motivi di prestazioni ed efficienza.

In questo caso, utilizzo le classi per rappresentare oggetti del mondo reale nella loro forma più ampia, uso le strutture per rappresentare oggetti più piccoli che hanno usi più precisi. Il modo in cui l'hai detto, "un insieme più coeso". La parola chiave è coesivo. Le classi saranno più elementi orientati agli oggetti, mentre le strutture possono avere alcune di quelle caratteristiche, sebbene su scala minore. IMO.

Li uso molto nei tag Treeview e Listview in cui è possibile accedere molto rapidamente agli attributi statici comuni. Ho sempre lottato per ottenere queste informazioni in un altro modo. Ad esempio, nelle mie applicazioni di database, utilizzo un Treeview in cui ho tabelle, SP, funzioni o qualsiasi altro oggetto. Creo e popolo la mia struttura, la inserisco nel tag, la tiro fuori, ottengo i dati della selezione e così via. Non lo farei con una lezione!

Cerco di mantenerli piccoli, li uso in situazioni di istanza singola e impedisco loro di cambiare. È prudente essere consapevoli della memoria, dell'allocazione e delle prestazioni. E i test sono così necessari.

La mia regola è

1, usa sempre la classe;

2, Se si verificano problemi di prestazioni, provo a modificare alcune classi per strutturare a seconda delle regole menzionate da @IAbstract, quindi eseguo un test per vedere se queste modifiche possono migliorare le prestazioni.

Una classe è un tipo di riferimento. Quando viene creato un oggetto della classe, la variabile a cui è assegnato l'oggetto contiene solo un riferimento a quella memoria. Quando il riferimento all'oggetto viene assegnato a una nuova variabile, la nuova variabile si riferisce all'oggetto originale. Le modifiche apportate tramite una variabile si riflettono nell'altra variabile perché si riferiscono entrambi agli stessi dati. Una struttura è un tipo di valore. Quando viene creata una struttura, la variabile a cui è assegnata la struttura contiene i dati effettivi della struttura. Quando la struttura viene assegnata a una nuova variabile, viene copiata. La nuova variabile e la variabile originale contengono quindi due copie separate degli stessi dati. Le modifiche apportate a una copia non influiscono sull'altra copia. In generale, le classi vengono utilizzate per modellare comportamenti più complessi o dati che si intende modificare dopo la creazione di un oggetto di classe.

Classi e strutture (Guida per programmatori C #)

MITO # 1: LE STRUTTURE SONO LE CLASSI LEGGEREZZA

Questo mito si presenta in una varietà di forme. Alcune persone credono che i tipi di valore non possano o non debbano avere metodi o altri comportamenti significativi: dovrebbero essere usati come semplici tipi di trasferimento di dati, con solo campi pubblici o proprietà semplici. Il tipo DateTime è un buon controesempio a questo: ha senso che sia un tipo di valore, in termini di essere un'unità fondamentale come un numero o un carattere, e ha anche senso che sia in grado di eseguire calcoli basati su il suo valore. Osservando le cose dall'altra direzione, i tipi di trasferimento dei dati dovrebbero spesso essere comunque dei tipi di riferimento: la decisione dovrebbe essere basata sul valore desiderato o sulla semantica del tipo di riferimento, non sulla semplicità del tipo. Altre persone credono che i tipi di valore siano "più leggeri" dei tipi di riferimento in termini di prestazioni. La verità è che in alcuni casi i tipi di valore sono più performanti: non richiedono la garbage collection a meno che non siano inscatolati, non abbiano l'identificazione del tipo in testa e non richiedano il dereferenziamento, per esempio. Ma in altri modi, i tipi di riferimento sono più performanti: il passaggio dei parametri, l'assegnazione di valori alle variabili, i valori di ritorno e operazioni simili richiedono solo 4 o 8 byte per essere copiati (a seconda che si stia eseguendo il CLR a 32 o 64 bit ) anziché copiare tutti i dati. Immagina se ArrayList fosse in qualche modo un tipo di valore "puro" e passare un'espressione ArrayList a un metodo implicava la copia di tutti i suoi dati! In quasi tutti i casi, le prestazioni non sono comunque determinate da questo tipo di decisione. I colli di bottiglia non sono quasi mai dove pensi che saranno, e prima di prendere una decisione di progettazione basata sulle prestazioni, dovresti misurare le diverse opzioni. Vale la pena notare che la combinazione delle due credenze non funziona neanche. Non importa quanti metodi abbia un tipo (che sia una classe o una struttura): la memoria presa per istanza non è interessata. (C'è un costo in termini di memoria occupata per il codice stesso, ma è sostenuta una volta anziché per ogni istanza.)

MITO # 2: TIPI DI RIFERIMENTO IN DIRETTA SUL CUORE; TIPI DI VALORE IN DIRETTA SULLE PILE

Questo è spesso causato dalla pigrizia da parte della persona che lo ripete. La prima parte è corretta: un'istanza di un tipo di riferimento viene sempre creata sull'heap. È la seconda parte che causa problemi. Come ho già notato, il valore di una variabile vive ovunque sia dichiarato, quindi se hai una classe con una variabile di istanza di tipo int, il valore di quella variabile per un dato oggetto sarà sempre dove si trova il resto dei dati per l'oggetto: sul mucchio. Solo le variabili locali (variabili dichiarate nei metodi) e i parametri del metodo vivono nello stack. In C # 2 e versioni successive, anche alcune variabili locali non vivono realmente nello stack, come vedrai quando esamineremo metodi anonimi nel capitolo 5. QUESTI CONCETTI SONO RILEVANTI ORA? È discutibile che se stai scrivendo un codice gestito, dovresti lasciare che il runtime si preoccupi del modo in cui la memoria viene utilizzata al meglio. Infatti, le specifiche del linguaggio non forniscono garanzie su ciò che vive dove; un runtime futuro potrebbe essere in grado di creare alcuni oggetti nello stack se sa che può cavarsela o il compilatore C # potrebbe generare codice che difficilmente utilizza lo stack. Il prossimo mito è di solito solo una questione terminologica.

MITO # 3: GLI OGGETTI SONO PASSATI PER RIFERIMENTO IN C # DA DEFAULT

Questo è probabilmente il mito più diffuso. Ancora una volta, le persone che fanno questa affermazione spesso (anche se non sempre) sanno come si comporta effettivamente C #, ma non sanno cosa significhi realmente "passare per riferimento". Sfortunatamente, questo è fonte di confusione per le persone che sanno cosa significa. La definizione formale di pass by reference è relativamente complicata, coinvolgendo i valori l e una terminologia informatica simile, ma l'importante è che se si passa una variabile per riferimento, il metodo che si sta chiamando può cambiare il valore della variabile del chiamante modificando il valore del parametro. Ora, ricorda che il valore di una variabile del tipo di riferimento è il riferimento, non l'oggetto stesso. È possibile modificare il contenuto dell'oggetto a cui fa riferimento un parametro senza che il parametro stesso venga passato per riferimento. Per esempio,

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

Quando viene chiamato questo metodo, il valore del parametro (un riferimento a StringBuilder) viene passato per valore. Se dovessi cambiare il valore della variabile del builder all'interno del metodo — per esempio, con l'istruzione builder = null; — quel cambiamento non verrebbe visto dal chiamante, contrariamente al mito. È interessante notare che non solo il bit "per riferimento" del mito è impreciso, ma lo è anche il bit "oggetti passati". Gli oggetti stessi non vengono mai passati, né per riferimento né per valore. Quando è coinvolto un tipo di riferimento, la variabile viene passata per riferimento o il valore dell'argomento (il riferimento) viene passato per valore. A parte qualsiasi altra cosa, questo risponde alla domanda su cosa succede quando null viene usato come argomento per valore-se gli oggetti vengono passati in giro, ciò causerebbe problemi, poiché non ci sarebbe un oggetto da passare! Anziché, il riferimento null viene passato per valore allo stesso modo di qualsiasi altro riferimento. Se questa breve spiegazione ti ha lasciato perplesso, potresti voler guardare il mio articolo, "Parametro che passa in C #" (http://mng.bz/otVt ), che fornisce ulteriori dettagli. Questi miti non sono i soli in circolazione. Pugilato e unboxing arrivano per la loro giusta dose di incomprensioni, che proverò a chiarire in seguito.

Riferimento: C # in Depth 3rd Edition di Jon Skeet

Penso che una buona prima approssimazione sia "mai".

Penso che una buona seconda approssimazione sia "mai".

Se sei alla disperata ricerca di perf, considerali, ma poi misura sempre.

Avevo solo a che fare con la pipa denominata Windows Communication Foundation [WCF] e ho notato che ha senso usare Struct per garantire che lo scambio di dati sia di tipo valore anziché di tipo di riferimento .

C # struct è un'alternativa leggera a una classe. Può fare quasi lo stesso di una classe, ma è meno "costoso" usare una struttura piuttosto che una classe. Il motivo di ciò è un po 'tecnico, ma per riassumere, le nuove istanze di una classe vengono posizionate nell'heap, dove le strutture di nuova istanza vengono posizionate nello stack. Inoltre, non hai a che fare con riferimenti a strutture, come con le classi, ma lavori direttamente con l'istanza struct. Ciò significa anche che quando si passa una struttura a una funzione, è per valore, anziché come riferimento. C'è di più al riguardo nel capitolo sui parametri delle funzioni.

Quindi, dovresti usare le strutture quando desideri rappresentare strutture di dati più semplici, e specialmente se sai che ne creerai un'istanza. Esistono molti esempi nel framework .NET, in cui Microsoft ha utilizzato le strutture anziché le classi, ad esempio la struttura Point, Rectangle e Color.

Struct può essere utilizzato per migliorare le prestazioni della garbage collection. Mentre di solito non devi preoccuparti delle prestazioni del GC, ci sono scenari in cui può essere un killer. Come cache di grandi dimensioni in applicazioni a bassa latenza. Vedi questo post per un esempio:

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

I tipi di struttura o valore possono essere utilizzati nei seguenti scenari:

1. Se si desidera impedire che l'oggetto venga raccolto dalla garbage collection.
2. Se è un tipo semplice e nessuna funzione membro modifica i suoi campi di istanza
3. Se non è necessario derivare da altri tipi o essere derivati ​​da altri tipi.

Puoi saperne di più sui tipi di valore e sui tipi di valori qui su questo link

In breve, usa struct se:

1- non è necessario modificare le proprietà / i campi dell'oggetto. Voglio dire, vuoi solo dare loro un valore iniziale e poi leggerli.

2- proprietà e campi nel tuo oggetto sono di tipo valore e non sono così grandi.

In tal caso, puoi sfruttare le strutture per prestazioni migliori e allocazione della memoria ottimizzata poiché utilizzano solo stack anziché stack e heap (in classe)

Uso raramente uno struct per le cose. Ma sono solo io. Dipende se ho bisogno che l'oggetto sia nullable o no.

Come indicato in altre risposte, utilizzo le classi per oggetti del mondo reale. Ho anche la mentalità di strutture utilizzate per la memorizzazione di piccole quantità di dati.

Le strutture sono per lo più come classi / oggetti. La struttura può contenere funzioni, membri e può essere ereditata. Ma le strutture sono in C # utilizzate solo per la conservazione dei dati . Le strutture richiedono meno RAM delle classi e sono più facili da raccogliere per Garbage Collector . Ma quando usi le funzioni nella tua struttura, il compilatore prende effettivamente quella struttura in modo molto simile a classe / oggetto, quindi se vuoi qualcosa con funzioni, allora usa classe / oggetto .