Quand faut-il utiliser struct et pas class en C #? Mon modèle conceptuel est que les structures sont utilisées à des moments où l'élément n'est qu'une collection de types de valeur . Une façon de les logiquement tous tenir ensemble dans un ensemble cohérent.

Je suis tombé sur ces règles ici :

• Une structure doit représenter une seule valeur.
• Une structure doit avoir une empreinte mémoire inférieure à 16 octets.
• Une structure ne doit pas être modifiée après sa création.

Ces règles fonctionnent-elles? Que signifie une structure sémantiquement?

La source référencée par l'OP a une certaine crédibilité ... mais qu'en est-il de Microsoft - quelle est la position sur l'utilisation des structures? J'ai cherché un apprentissage supplémentaire auprès de Microsoft , et voici ce que j'ai trouvé:

Envisagez de définir une structure au lieu d'une classe si les instances du type sont petites et généralement de courte durée ou sont généralement intégrées dans d'autres objets.

Ne définissez une structure que si le type possède toutes les caractéristiques suivantes:

1. Il représente logiquement une valeur unique, similaire aux types primitifs (entier, double, etc.).
2. Il a une taille d'instance inférieure à 16 octets.
3. C'est immuable.
4. Il n'aura pas à être emballé fréquemment.

Microsoft viole systématiquement ces règles

D'accord, n ° 2 et n ° 3 de toute façon. Notre dictionnaire bien-aimé a 2 structures internes:

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

* Source de référence

La source 'JonnyCantCode.com' a obtenu 3 sur 4 - tout à fait pardonnable car # 4 ne serait probablement pas un problème. Si vous vous retrouvez en train de boxer une structure, repensez votre architecture.

Voyons pourquoi Microsoft utiliserait ces structures:

1. Chaque structure Entryet Enumeratorreprésentent des valeurs uniques.
2. La vitesse
3. Entryn'est jamais passé en tant que paramètre en dehors de la classe Dictionary. Une enquête plus approfondie montre que pour satisfaire l'implémentation de IEnumerable, Dictionary utilise la Enumeratorstructure qu'il copie chaque fois qu'un énumérateur est demandé ... est logique.
4. Interne à la classe Dictionary. Enumeratorest public car Dictionary est énumérable et doit avoir une accessibilité égale à l'implémentation de l'interface IEnumerator - par exemple le getter IEnumerator.

Mise à jour - En outre, sachez que lorsqu'une structure implémente une interface - comme le fait l'énumérateur - et est convertie en ce type implémenté, la structure devient un type de référence et est déplacée vers le segment de mémoire. En interne à la classe Dictionary, Enumerator est toujours un type de valeur. Cependant, dès qu'une méthode appelle GetEnumerator(), un type de référence IEnumeratorest renvoyé.

Ce que nous ne voyons pas ici, c'est une tentative ou une preuve d'exigence de garder les structures immuables ou de maintenir une taille d'instance de seulement 16 octets ou moins:

1. Rien dans les structures ci-dessus n'est déclaré readonly- non immuable
2. La taille de ces structures pourrait être bien supérieure à 16 octets
3. Entrya une durée de vie indéterminée (à partir de Add(), à Remove(), Clear()ou la collecte des ordures);

Et ... 4. Les deux structures stockent TKey et TValue, qui, nous le savons tous, sont tout à fait capables d'être des types de référence (informations bonus ajoutées)

Malgré les clés hachées, les dictionnaires sont rapides en partie parce que l'instanciation d'une structure est plus rapide qu'un type de référence. Ici, j'ai un Dictionary<int, int>qui stocke 300 000 entiers aléatoires avec des clés incrémentées séquentiellement.

Capacité: 312874
MemSize: 2660827 octets
Redimensionnement terminé: 5 ms
Temps total de remplissage: 889 ms

Capacité : nombre d'éléments disponibles avant le redimensionnement du tableau interne.

MemSize : déterminé en sérialisant le dictionnaire dans un MemoryStream et en obtenant une longueur d'octet (suffisamment précise pour nos besoins).

Redimensionnement terminé : le temps nécessaire pour redimensionner la matrice interne de 150862 éléments à 312874 éléments. Lorsque vous pensez que chaque élément est copié séquentiellement via Array.CopyTo(), ce n'est pas trop minable.

Temps total à remplir : certes biaisé en raison de la journalisation et d'un OnResizeévénement que j'ai ajouté à la source; cependant, toujours impressionnant pour remplir 300k entiers tout en redimensionnant 15 fois pendant l'opération. Par simple curiosité, quel serait le temps total à remplir si je connaissais déjà la capacité? 13ms

Alors, maintenant, et si Entryc'était une classe? Ces temps ou mesures différeraient-ils vraiment autant?

Capacité: 312874
MemSize: 2660827 octets
Redimensionnement terminé: 26ms
Temps total de remplissage: 964ms

De toute évidence, la grande différence réside dans le redimensionnement. Une différence si le dictionnaire est initialisé avec la capacité? Pas assez pour se préoccuper de ... 12ms .

Ce qui se passe est, car Entryest une structure, elle ne nécessite pas d'initialisation comme un type de référence. C'est à la fois la beauté et le fléau du type valeur. Afin de l'utiliser Entrycomme type de référence, j'ai dû insérer le code suivant:

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

La raison pour laquelle j'ai dû initialiser chaque élément de tableau en Entrytant que type de référence se trouve sur MSDN: Structure Design . En bref:

Ne fournissez pas de constructeur par défaut pour une structure.

Si une structure définit un constructeur par défaut, lorsque des tableaux de la structure sont créés, le Common Language Runtime exécute automatiquement le constructeur par défaut sur chaque élément du tableau.

Certains compilateurs, tels que le compilateur C #, ne permettent pas aux structures d'avoir des constructeurs par défaut.

C'est en fait assez simple et nous emprunterons aux Trois lois de la robotique d'Asimov :

1. La structure doit être sûre à utiliser
2. La structure doit remplir sa fonction efficacement, sauf si cela enfreindrait la règle # 1
3. La structure doit rester intacte pendant son utilisation, sauf si sa destruction est requise pour satisfaire à la règle n ° 1.

... que retenons-nous de cela : bref, soyez responsable de l'utilisation des types de valeur. Ils sont rapides et efficaces, mais ont la capacité de provoquer de nombreux comportements inattendus s'ils ne sont pas correctement entretenus (c'est-à-dire des copies involontaires).

Quand tu:

1. pas besoin de polymorphisme,
2. veulent une sémantique de valeur, et
3. veulent éviter l'allocation de segments de mémoire et les frais généraux de récupération de place associés.

La mise en garde, cependant, est que les structures (arbitrairement grandes) sont plus coûteuses à transmettre que les références de classe (généralement un mot machine), donc les classes pourraient finir par être plus rapides dans la pratique.

Je ne suis pas d'accord avec les règles données dans le message d'origine. Voici mes règles:

1) Vous utilisez des structures pour les performances lorsqu'elles sont stockées dans des tableaux. (voir aussi Quand les structures sont-elles la réponse? )

2) Vous en avez besoin dans le code en passant des données structurées vers / depuis C / C ++

3) N'utilisez pas de structures sauf si vous en avez besoin:

• Ils se comportent différemment des "objets normaux" ( types de référence ) sous affectation et lors du passage en arguments, ce qui peut conduire à un comportement inattendu; cela est particulièrement dangereux si la personne qui regarde le code ne sait pas qu'il s'agit d'un struct.
• Ils ne peuvent pas être hérités.
• Passer des structures comme arguments est plus cher que les classes.

Utilisez une structure lorsque vous voulez une sémantique de valeur par opposition à une sémantique de référence.

Éditer

Je ne sais pas pourquoi les gens votent en faveur de cela, mais c'est un point valable, et cela a été fait avant que l'op clarifie sa question, et c'est la raison fondamentale la plus fondamentale d'une structure.

Si vous avez besoin d'une sémantique de référence, vous avez besoin d'une classe et non d'une structure.

En plus de la réponse "c'est une valeur", un scénario spécifique pour l'utilisation de structures est lorsque vous savez que vous avez un ensemble de données qui provoque des problèmes de récupération de place et que vous avez beaucoup d'objets. Par exemple, une grande liste / tableau d'instances Personne. La métaphore naturelle ici est une classe, mais si vous avez un grand nombre d'instances de personne à longue durée de vie, elles peuvent finir par obstruer GEN-2 et provoquer des blocages GC. Si le scénario le justifie, une approche potentielle ici consiste à utiliser un tableau (pas une liste) de structures Person , c'est-à-dire Person[]. Maintenant, au lieu d'avoir des millions d'objets dans GEN-2, vous avez un seul morceau sur la LOH (je suppose qu'il n'y a pas de chaînes, etc. ici - c'est-à-dire une valeur pure sans aucune référence). Cela a très peu d'impact sur le GC.

Travailler avec ces données est gênant, car les données sont probablement trop grandes pour une structure, et vous ne voulez pas copier les valeurs de graisse tout le temps. Cependant, y accéder directement dans un tableau ne copie pas la structure - elle est en place (contrairement à un indexeur de liste, qui copie). Cela signifie beaucoup de travail avec les index:

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

Notez que garder les valeurs elles-mêmes immuables aidera ici. Pour une logique plus complexe, utilisez une méthode avec un paramètre by-ref:

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

Encore une fois, cela est en place - nous n'avons pas copié la valeur.

Dans des scénarios très spécifiques, cette tactique peut être très efficace; cependant, c'est un scernario assez avancé qui ne devrait être tenté que si vous savez ce que vous faites et pourquoi. La valeur par défaut ici serait une classe.

De la spécification du langage C # :

1.7 Structs

Comme les classes, les structures sont des structures de données qui peuvent contenir des membres de données et des membres de fonction, mais contrairement aux classes, les structures sont des types de valeur et ne nécessitent pas d'allocation de segment de mémoire. Une variable d'un type struct stocke directement les données de la structure, tandis qu'une variable d'un type class stocke une référence à un objet alloué dynamiquement. Les types de structures ne prennent pas en charge l'héritage spécifié par l'utilisateur, et tous les types de structures héritent implicitement de l'objet type.

Les structures sont particulièrement utiles pour les petites structures de données qui ont une sémantique de valeur. Les nombres complexes, les points dans un système de coordonnées ou les paires clé-valeur dans un dictionnaire sont tous de bons exemples de structures. L'utilisation de structures plutôt que de classes pour les petites structures de données peut faire une grande différence dans le nombre d'allocations de mémoire qu'une application effectue. Par exemple, le programme suivant crée et initialise un tableau de 100 points. Avec Point implémenté en tant que classe, 101 objets distincts sont instanciés, un pour le tableau et un pour les 100 éléments.

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

Une alternative est de faire de Point une structure.

struct Point
{
   public int x, y;

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

Désormais, un seul objet est instancié, celui du tableau, et les instances Point sont stockées en ligne dans le tableau.

Les constructeurs de structures sont invoqués avec le nouvel opérateur, mais cela n'implique pas que la mémoire est allouée. Au lieu d'allouer dynamiquement un objet et de lui renvoyer une référence, un constructeur de structure renvoie simplement la valeur de structure elle-même (généralement dans un emplacement temporaire sur la pile), et cette valeur est ensuite copiée si nécessaire.

Avec les classes, il est possible que deux variables référencent le même objet et donc possible que les opérations sur une variable affectent l'objet référencé par l'autre variable. Avec les structures, les variables ont chacune leur propre copie des données, et il n'est pas possible que les opérations sur l'une affectent l'autre. Par exemple, la sortie produite par le fragment de code suivant dépend si Point est une classe ou une structure.

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

Si Point est une classe, la sortie est 20 car a et b font référence au même objet. Si Point est une structure, la sortie est 10 car l'affectation de a à b crée une copie de la valeur, et cette copie n'est pas affectée par l'affectation suivante à ax

L'exemple précédent met en évidence deux des limitations des structures. Premièrement, la copie d'une structure entière est généralement moins efficace que la copie d'une référence d'objet, de sorte que l'attribution et le passage de paramètres de valeur peuvent être plus coûteux avec des structures qu'avec des types de référence. Deuxièmement, à l'exception des paramètres ref et out, il n'est pas possible de créer des références à des structures, ce qui exclut leur utilisation dans un certain nombre de situations.

Les structures sont bonnes pour la représentation atomique des données, où lesdites données peuvent être copiées plusieurs fois par le code. Le clonage d'un objet est en général plus coûteux que la copie d'une structure, car cela implique d'allouer de la mémoire, d'exécuter le constructeur et de désallouer / garbage collection lorsque vous en avez terminé.

Voici une règle de base.

• Si tous les champs membres sont des types de valeur, créez une structure .

• Si un champ membre est un type de référence, créez une classe . Cela est dû au fait que le champ de type de référence aura quand même besoin de l'allocation de segment de mémoire.

Exemples

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
}

Premièrement: scénarios d'interopérabilité ou lorsque vous devez spécifier la disposition de la mémoire

Deuxièmement: quand les données ont presque la même taille qu'un pointeur de référence de toute façon.

Vous devez utiliser un "struct" dans les situations où vous souhaitez spécifier explicitement la disposition de la mémoire à l'aide de StructLayoutAttribute - généralement pour PInvoke.

Edit: Comment souligne que vous pouvez utiliser une classe ou une structure avec StructLayoutAttribute et c'est certainement vrai. En pratique, vous utiliseriez généralement une structure - elle est allouée sur la pile par rapport au tas, ce qui est logique si vous passez simplement un argument à un appel de méthode non managé.

J'utilise des structures pour emballer ou déballer toute sorte de format de communication binaire. Cela inclut la lecture ou l'écriture sur disque, les listes de sommets DirectX, les protocoles réseau ou le traitement des données chiffrées / compressées.

Les trois lignes directrices que vous énumérez ne m'ont pas été utiles dans ce contexte. Quand j'ai besoin d'écrire quatre cents octets de choses dans un ordre particulier, je vais définir une structure de quatre cents octets, et je vais le remplir avec toutes les valeurs non liées qu'il est censé avoir, et je vais pour le configurer de la manière la plus logique à l'époque. (D'accord, quatre cents octets seraient assez étranges - mais à l'époque où j'écrivais des fichiers Excel pour gagner ma vie, je faisais face à des structures pouvant aller jusqu'à une quarantaine d'octets partout, car c'est la taille de certains enregistrements BIFF.)

À l'exception des types de valeurs qui sont utilisés directement par le runtime et divers autres à des fins PInvoke, vous ne devez utiliser les types de valeurs que dans 2 scénarios.

1. Lorsque vous avez besoin de copier la sémantique.
2. Lorsque vous avez besoin d'une initialisation automatique, normalement dans des tableaux de ces types.

.NET prend en charge value typeset reference types(en Java, vous ne pouvez définir que des types de référence). Les instances de reference typesget sont allouées dans le tas managé et sont récupérées quand il n'y a aucune référence en suspens à elles. Les instances de value types, d'autre part, sont allouées dans le stack, et donc la mémoire allouée est récupérée dès que leur portée se termine. Et bien sûr, value typespassez par la valeur, etreference types par référence. Tous les types de données primitifs C #, à l'exception de System.String, sont des types de valeur.

Quand utiliser struct sur classe,

En C #, structssont value types, les classes sont reference types. Vous pouvez créer des types de valeur, en C #, à l'aide du enummot-clé et du structmot - clé. L'utilisation d'un value typeau lieu d'un reference typeentraînera moins d'objets sur le tas géré, ce qui se traduira par une charge moindre sur le garbage collector (GC), des cycles GC moins fréquents et par conséquent de meilleures performances. Cependant, ils value typesont aussi leurs inconvénients. Faire le tour d'un gros structest certainement plus coûteux que de passer une référence, c'est un problème évident. L'autre problème est la surcharge associée à boxing/unboxing. Si vous vous demandez ce boxing/unboxingque cela signifie, suivez ces liens pour une bonne explication boxingetunboxing. En dehors des performances, il y a des moments où vous avez simplement besoin que les types aient une sémantique de valeur, ce qui serait très difficile (ou moche) à implémenter sireference typesêtes tout ce que vous avez. Vous ne devez utiliser value typesque lorsque vous avez besoin de copier la sémantique ou que vous avez besoin d'une initialisation automatique, normalement dans arraysces types.

Un struct est un type de valeur. Si vous affectez une structure à une nouvelle variable, la nouvelle variable contiendra une copie de l'original.

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

L'exécution des résultats suivants dans 5 instances de la structure stockée en mémoire:

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.

Une classe est un type de référence. Lorsque vous affectez une classe à une nouvelle variable, la variable contient une référence à l'objet de classe d'origine.

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

L'exécution des résultats suivants dans une seule instance de l'objet classe en mémoire.

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  

Les structures peuvent augmenter la probabilité d'une erreur de code. Si un objet valeur est traité comme un objet de référence mutable, un développeur peut être surpris lorsque des modifications apportées sont perdues de manière inattendue.

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

J'ai fait un petit benchmark avec BenchmarkDotNet pour avoir une meilleure compréhension de l'avantage "struct" en nombre. Je teste en boucle un tableau (ou une liste) de structures (ou classes). La création de ces tableaux ou listes est hors de portée du benchmark - il est clair que la «classe» est plus lourde utilisera plus de mémoire et impliquera GC.

La conclusion est donc: soyez prudent avec LINQ et les structures cachées boxing / unboxing et l'utilisation de structures pour les microoptimisations reste strictement avec les tableaux.

PS Un autre point de référence sur le passage de struct / classe à travers la pile d'appels est 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 |

Code:

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

Les types de structure en C # ou dans d'autres langages .net sont généralement utilisés pour contenir des éléments qui devraient se comporter comme des groupes de valeurs de taille fixe. Un aspect utile des types de structure est que les champs d'une instance de type structure peuvent être modifiés en modifiant l'emplacement de stockage dans lequel elle est conservée, et en aucune autre manière. Il est possible de coder une structure de telle manière que la seule façon de muter un champ est de construire une toute nouvelle instance, puis d'utiliser une affectation de structure pour muter tous les champs de la cible en les écrasant avec les valeurs de la nouvelle instance, mais à moins qu'un struct ne fournisse aucun moyen de créer une instance où ses champs ont des valeurs non par défaut, tous ses champs seront mutables si et si le struct lui-même est stocké dans un emplacement mutable.

Notez qu'il est possible de concevoir un type de structure afin qu'il se comporte essentiellement comme un type de classe, si la structure contient un champ de type classe privé et redirige ses propres membres vers celui de l'objet classe encapsulé. Par exemple, un PersonCollectionpourrait offrir des propriétés SortedByNameet SortedById, qui détiennent toutes deux une référence "immuable" à un PersonCollection(défini dans leur constructeur) et l'implémenter GetEnumeratoren appelant soit creator.GetNameSortedEnumeratorou creator.GetIdSortedEnumerator. De telles structures se comporteraient comme une référence à a PersonCollection, sauf que leurs GetEnumeratorméthodes seraient liées à différentes méthodes dans le PersonCollection. On pourrait également avoir une structure envelopper une partie d'un tableau (par exemple, on pourrait définir une ArrayRange<T>structure qui contiendrait un T[]appelé Arr, un intOffset et un intLength, Avec une propriété indexée qui, pour un index idxdans la plage 0 à Length-1, aurait accès Arr[idx+Offset]). Malheureusement, s'il foos'agit d'une instance en lecture seule d'une telle structure, les versions actuelles du compilateur n'autoriseront pas les opérations comme, foo[3]+=4;car elles n'ont aucun moyen de déterminer si ces opérations tenteront d'écrire dans les champs de foo.

Il est également possible de concevoir une structure pour se comporter comme un type de valeur similaire qui contient une collection de taille variable (qui semblera être copiée chaque fois que la structure est), mais la seule façon de faire fonctionner cela est de s'assurer qu'aucun objet auquel le struct détient une référence sera jamais exposée à tout ce qui pourrait la muter. Par exemple, on pourrait avoir une structure de type tableau qui contient un tableau privé, et dont la méthode "put" indexée crée un nouveau tableau dont le contenu est similaire à celui de l'original à l'exception d'un élément modifié. Malheureusement, il peut être quelque peu difficile de faire fonctionner efficacement ces structures. Bien qu'il y ait des moments où la sémantique des structures peut être pratique (par exemple, pouvoir passer une collection de type tableau à une routine, l'appelant et l'appelé sachant tous les deux que le code extérieur ne modifiera pas la collection,

Non - je ne suis pas entièrement d'accord avec les règles. Ce sont de bonnes lignes directrices à considérer avec les performances et la normalisation, mais pas à la lumière des possibilités.

Comme vous pouvez le voir dans les réponses, il existe de nombreuses façons créatives de les utiliser. Donc, ces directives doivent être simplement cela, toujours pour des raisons de performances et d'efficacité.

Dans ce cas, j'utilise des classes pour représenter des objets du monde réel dans leur plus grande forme, j'utilise des structures pour représenter des objets plus petits qui ont des utilisations plus exactes. Comme vous l'avez dit, "un tout plus cohérent". Le mot clé étant cohérent. Les classes seront davantage des éléments orientés objet, tandis que les structures peuvent avoir certaines de ces caractéristiques, bien qu'à une plus petite échelle. OMI.

Je les utilise beaucoup dans les balises Treeview et Listview où les attributs statiques communs sont accessibles très rapidement. J'ai toujours eu du mal à obtenir ces informations d'une autre manière. Par exemple, dans mes applications de base de données, j'utilise un Treeview où j'ai des tables, des SP, des fonctions ou tout autre objet. Je crée et remplis ma structure, la mets dans la balise, la retire, récupère les données de la sélection et ainsi de suite. Je ne ferais pas ça avec un cours!

J'essaie de les garder petits, de les utiliser dans des situations à instance unique et de les empêcher de changer. Il est prudent de connaître la mémoire, l'allocation et les performances. Et les tests sont tellement nécessaires.

Ma règle est

1, utilisez toujours la classe;

2, S'il y a un problème de performance, j'essaie de changer une classe en struct en fonction des règles mentionnées par @IAbstract, puis je fais un test pour voir si ces changements peuvent améliorer les performances.

Une classe est un type de référence. Lorsqu'un objet de la classe est créé, la variable à laquelle l'objet est affecté ne contient qu'une référence à cette mémoire. Lorsque la référence d'objet est affectée à une nouvelle variable, la nouvelle variable fait référence à l'objet d'origine. Les modifications apportées via une variable sont reflétées dans l'autre variable car elles font toutes deux référence aux mêmes données. Un struct est un type de valeur. Lorsqu'une structure est créée, la variable à laquelle la structure est affectée contient les données réelles de la structure. Lorsque la structure est affectée à une nouvelle variable, elle est copiée. La nouvelle variable et la variable d'origine contiennent donc deux copies distinctes des mêmes données. Les modifications apportées à une copie n'affectent pas l'autre copie. En général, les classes sont utilisées pour modéliser un comportement plus complexe ou des données destinées à être modifiées après la création d'un objet de classe.

Classes et structures (Guide de programmation C #)

MYTHE N ° 1: LES STRUCTS SONT DES CLASSES LÉGÈRES

Ce mythe se présente sous diverses formes. Certaines personnes croient que les types de valeur ne peuvent pas ou ne doivent pas avoir de méthodes ou d'autres comportements importants - ils doivent être utilisés comme de simples types de transfert de données, avec uniquement des champs publics ou des propriétés simples. Le type DateTime est un bon contre-exemple à cela: il est logique qu'il soit un type de valeur, en termes d'être une unité fondamentale comme un nombre ou un caractère, et il est également logique qu'il puisse effectuer des calculs basés sur Sa valeur. En regardant les choses dans l'autre sens, les types de transfert de données doivent souvent être des types de référence de toute façon - la décision doit être basée sur la valeur souhaitée ou la sémantique du type de référence, pas sur la simplicité du type. D'autres personnes pensent que les types de valeur sont «plus légers» que les types de référence en termes de performances. La vérité est que, dans certains cas, les types de valeur sont plus performants: ils ne nécessitent pas de récupération de place sauf s'ils sont encadrés, n'ont pas la surcharge d'identification de type et ne nécessitent pas de déréférencement, par exemple. Mais à d'autres égards, les types de référence sont plus performants: le passage de paramètres, l'attribution de valeurs à des variables, le retour de valeurs et des opérations similaires ne nécessitent que 4 ou 8 octets pour être copiés (selon que vous exécutez le CLR 32 bits ou 64 bits). ) plutôt que de copier toutes les données. Imaginez si ArrayList était en quelque sorte un type de valeur «pur», et passer une expression ArrayList à une méthode impliquait de copier toutes ses données! Dans presque tous les cas, les performances ne sont pas vraiment déterminées par ce type de décision de toute façon. Les goulots d'étranglement ne sont presque jamais là où vous pensez qu'ils seront, et avant de prendre une décision de conception basée sur les performances, vous devez mesurer les différentes options. Il convient de noter que la combinaison des deux croyances ne fonctionne pas non plus. Peu importe le nombre de méthodes d'un type (que ce soit une classe ou une structure), la mémoire utilisée par instance n'est pas affectée. (Il y a un coût en termes de mémoire occupée pour le code lui-même, mais il est engagé une fois plutôt que pour chaque instance.)

MYTHE # 2: LES TYPES DE RÉFÉRENCE VIVENT SUR LE CŒUR; TYPES DE VALEURS EN DIRECT SUR LA PILE

Celui-ci est souvent causé par la paresse de la personne qui le répète. La première partie est correcte: une instance d'un type de référence est toujours créée sur le tas. C'est la deuxième partie qui pose problème. Comme je l'ai déjà noté, la valeur d'une variable vit partout où elle est déclarée, donc si vous avez une classe avec une variable d'instance de type int, la valeur de cette variable pour un objet donné sera toujours là où le reste des données de l'objet est ... sur le tas. Seules les variables locales (variables déclarées dans les méthodes) et les paramètres de méthode vivent sur la pile. En C # 2 et versions ultérieures, même certaines variables locales ne vivent pas vraiment sur la pile, comme vous le verrez lorsque nous examinons les méthodes anonymes au chapitre 5. CES CONCEPTS SONT-ILS PERTINENTS MAINTENANT? On peut soutenir que si vous écrivez du code managé, vous devez laisser le runtime s'inquiéter de la meilleure façon d'utiliser la mémoire. En effet, la spécification de la langue ne garantit pas ce qui vit où; un futur runtime pourra peut-être créer des objets sur la pile s'il sait qu'il peut s'en tirer, ou le compilateur C # pourrait générer du code qui utilise à peine la pile. Le mythe suivant n'est généralement qu'un problème de terminologie.

MYTHE # 3: LES OBJETS SONT PASSÉS PAR RÉFÉRENCE EN C # PAR DÉFAUT

C'est probablement le mythe le plus répandu. Encore une fois, les personnes qui font cette affirmation savent souvent (mais pas toujours) comment se comporte réellement C #, mais elles ne savent pas ce que signifie «passer par référence». Malheureusement, cela prête à confusion pour les personnes qui savent ce que cela signifie. La définition formelle du passage par référence est relativement compliquée, impliquant des valeurs l et une terminologie informatique similaire, mais l'important est que si vous passez une variable par référence, la méthode que vous appelez peut changer la valeur de la variable de l'appelant en modifiant sa valeur de paramètre. Maintenant, rappelez-vous que la valeur d'une variable de type référence est la référence, pas l'objet lui-même. Vous pouvez modifier le contenu de l'objet auquel un paramètre fait référence sans que le paramètre lui-même soit transmis par référence. Par exemple,

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

Lorsque cette méthode est appelée, la valeur du paramètre (une référence à un StringBuilder) est passée par valeur. Si vous deviez changer la valeur de la variable de générateur dans la méthode - par exemple, avec l'instruction builder = null; - ce changement ne serait pas vu par l'appelant, contrairement au mythe. Il est intéressant de noter que non seulement le bit «par référence» du mythe est inexact, mais aussi le bit «les objets sont passés». Les objets eux-mêmes ne sont jamais transmis, ni par référence ni par valeur. Lorsqu'un type de référence est impliqué, la variable est transmise par référence ou la valeur de l'argument (la référence) est transmise par valeur. En plus de toute autre chose, cela répond à la question de savoir ce qui se passe lorsque null est utilisé comme argument par valeur - si des objets étaient transmis, cela causerait des problèmes, car il n'y aurait pas d'objet à passer! Au lieu, la référence nulle est passée par valeur de la même manière que toute autre référence. Si cette explication rapide vous a laissé perplexe, vous voudrez peut-être consulter mon article, «Passage de paramètres en C #» (http://mng.bz/otVt ), qui va beaucoup plus en détail. Ces mythes ne sont pas les seuls à exister. La boxe et le déballage arrivent pour leur juste part de malentendus, que j'essaierai de clarifier ensuite.

Référence: C # in Depth 3rd Edition par Jon Skeet

Je pense qu'une bonne première approximation est "jamais".

Je pense qu'une bonne seconde approximation est "jamais".

Si vous avez désespérément besoin de perf, considérez-les, mais mesurez toujours.

Je venais de traiter avec le canal nommé Windows Communication Foundation [WCF] et j'ai remarqué qu'il est logique d'utiliser Structs afin de garantir que l'échange de données est de type valeur au lieu de type référence .

La structure C # est une alternative légère à une classe. Il peut faire presque la même chose qu'une classe, mais il est moins «coûteux» d'utiliser une structure plutôt qu'une classe. La raison en est un peu technique, mais pour résumer, de nouvelles instances d'une classe sont placées sur le tas, où les structures nouvellement instanciées sont placées sur la pile. De plus, vous ne traitez pas avec des références à des structures, comme avec des classes, mais à la place vous travaillez directement avec l'instance de structure. Cela signifie également que lorsque vous passez une structure à une fonction, c'est par valeur, plutôt que comme référence. Il y a plus à ce sujet dans le chapitre sur les paramètres de fonction.

Donc, vous devez utiliser des structures lorsque vous souhaitez représenter des structures de données plus simples, et surtout si vous savez que vous en instancierez beaucoup. Il existe de nombreux exemples dans le framework .NET, où Microsoft a utilisé des structures au lieu de classes, par exemple la structure Point, Rectangle et Color.

Struct peut être utilisé pour améliorer les performances de la récupération de place. Bien que vous n'ayez généralement pas à vous soucier des performances du GC, il existe des scénarios où cela peut être un tueur. Comme les grands caches dans les applications à faible latence. Voir cet article pour un exemple:

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

Les types de structure ou de valeur peuvent être utilisés dans les scénarios suivants -

1. Si vous souhaitez empêcher la collecte de l'objet par garbage collection.
2. S'il s'agit d'un type simple et qu'aucune fonction membre ne modifie ses champs d'instance
3. S'il n'est pas nécessaire de dériver d'autres types ou d'être dérivé vers d'autres types.

Vous pouvez en savoir plus sur les types de valeurs et les types de valeurs ici sur ce lien

En bref, utilisez struct si:

1- Les propriétés / champs de votre objet n'ont pas besoin d'être modifiés. Je veux dire que vous voulez simplement leur donner une valeur initiale, puis les lire.

2- Les propriétés et les champs de votre objet sont de type valeur et ils ne sont pas si grands.

Si c'est le cas, vous pouvez profiter des structures pour de meilleures performances et une allocation de mémoire optimisée car elles n'utilisent que des piles plutôt que des piles et des tas (en classes)

J'utilise rarement une structure pour les choses. Mais c'est juste moi. Cela dépend si j'ai besoin que l'objet soit nul ou non.

Comme indiqué dans d'autres réponses, j'utilise des classes pour des objets du monde réel. J'ai également l'état d'esprit des structures utilisées pour stocker de petites quantités de données.

Les structures sont dans la plupart des cas comme des classes / objets. La structure peut contenir des fonctions, des membres et peut être héritée. Mais les structures sont en C # utilisées uniquement pour la conservation des données . Les structures prennent moins de RAM que les classes et sont plus faciles à collecter pour le garbage collector . Mais lorsque vous utilisez des fonctions dans votre structure, le compilateur prend en fait cette structure de la même manière que classe / objet, donc si vous voulez quelque chose avec des fonctions, alors utilisez classe / objet .