C# : Public Static readonly vs const

Question

J'ai lu environ const et static readonly champs. Nous avons des classes qui ne contient que des valeurs constantes. Utilisé pour différentes choses dans notre système. Alors je me demande si mon observation est correcte:

Si ces genre de valeurs de constante toujours être static readonly pour tout ce qui est public? Et de n'utiliser const interne/protected/private valeurs?

Que recommandez-vous? Devrais-je peut-être même pas utiliser static readonly champs, mais plutôt d'utiliser les propriétés de peut-être?

Answer 1

Public static readonly champs sont un peu inhabituel; public static propriétés (avec seulement un get) serait la plus courante (peut-être soutenu par une private static readonly champ).

Const valeurs sont gravées directement dans l'appel-site; c'est à double tranchant:

• il est inutile si la valeur est extraite au moment de l'exécution, peut-être de config
• si vous modifiez la valeur d'un const, vous avez besoin de reconstruire tous les clients
• mais il peut être plus rapide, car elle permet d'éviter un appel de méthode...
• ...ce qui pourrait parfois avoir été incorporé par le JIT de toute façon

Si la valeur ne risque jamais à changer, const est bien - Zero etc raisonnables consts ;-p Autre que cela, les propriétés statiques sont les plus fréquentes.

Answer 2

Je voudrais utiliser Shared readonly si le consommateur se trouve dans un assembly différent. Avoir la const et le consommateur dans les deux assemblées de DIF est une belle façon de se tirer dans le pied.

Answer 3

D’autres choses

const int un

• doit être initialisée
• l’initialisation doit être au moment de la compilation

readonly int un

• pouvez utiliser la valeur par défaut, sans initialiser
• l’initialisation peut être en cours d’exécution

Answer 4

C'est juste un supplément pour les autres réponses. Je ne vais pas les répéter (maintenant quatre ans plus tard).

Il y a des situations où un const et un non-const ont des sémantiques différentes. Par exemple:

const int y = 42;

static void Main()
{
  short x = 42;
  Console.WriteLine(x.Equals(y));
}

imprime True, considérant ce qui suit:

static readonly int y = 42;

static void Main()
{
  short x = 42;
  Console.WriteLine(x.Equals(y));
}

écrit False.

La raison en est que la méthode x.Equals a deux surcharges, celle qui prend en short (System.Int16) et celui qui prend un object (System.Object). Maintenant, la question est de savoir si l'un ou les deux s'appliquent, avec mon y argument.

Lors de l' y est une constante de compilation (littérale), l' const de cas, il devient important qu'il existe une conversion implicite de int de short à condition que l' int est une constante, et à condition que le compilateur C# vérifie que sa valeur est dans la gamme d'un short ( 42 ). Voir Implicite de l'expression constante de conversions dans la Spécification du Langage C#. Donc, à la fois les surcharges doivent être considérés. La surcharge Equals(short) est préféré (tout short est object, mais pas tous, object sont short). Donc, y est converti short, et que la surcharge est utilisé. Ensuite, Equals compare deux short de la valeur identique, et qui donne des true.

Lors de l' y n'est pas une constante, pas d' implicite de conversion de int de short existe. C'est parce qu'en général, un int peut être trop grande pour tenir dans une short. ( Explicite de conversion n'existe pas, mais je n'ai pas dit Equals((short)y), ce qui n'est pas pertinent.) Nous voyons qu'un seul surcharge s'applique, l' Equals(object) . Donc, y est en boîte de object. Ensuite, Equals va comparer un System.Int16 d'un System.Int32, et depuis le moment de l'exécution de types ne sont même pas d'accord, qui donnera false.

Nous concluons que, dans certains (rares) cas, le changement d'un const type de membre à un static readonly domaine (ou dans l'autre sens, quand c'est possible) peut modifier le comportement du programme.

Answer 5

Une chose à noter est const est limité aux types primitifs/valeur (l’exception étant les cordes)