31 votes

C # utilisant des consts dans des classes statiques

J'ai été à bosser sur un projet open source, ce week-end passé, quand je suis tombé sur un peu de code qui me troublait de rechercher l'utilisation de la spécification C# .

Le code en question est comme suit:

internal static class SomeStaticClass
{
    private const int CommonlyUsedValue = 42;

    internal static string UseCommonlyUsedValue(...)
    {
        // some code
        value = CommonlyUsedValue + ...;

        return value.ToString();
    }
}

J'ai été surpris parce que cela semble être un champ statique utilisé par une fonction statique qui d'une façon ou compilé très bien dans une classe statique!

La spécification des états (§10.4):

Une constante-déclaration peut inclure un un ensemble d'attributs (§17), un nouveau modificateur (§10.3.4), et valide la combinaison des quatre accès les modificateurs (§10.3.5). Les attributs et les modificateurs s'appliquent à tous les les membres déclarés par le constant-déclaration. Même si les constantes sont considérés comme statiques membres, une constante de la déclaration de ne nécessite ni ne permet une statique modificateur. C'est une erreur pour la même modificateur d'apparaître plusieurs fois dans un déclaration de constante.

Alors maintenant, il fait un peu plus de sens parce que les constantes sont considérés comme des membres statiques, mais le reste de la phrase est un peu surprenant pour moi. Pourquoi est-ce qu' une constante déclaration ne nécessite ni ne permet une statique modificateur? Certes je ne connais pas les specs assez bien pour cela de faire sens, en premier lieu, mais pourquoi la décision de ne pas forcer constantes à utiliser le modificateur static si elles sont considérées comme statique?

En regardant la dernière phrase de ce paragraphe, je ne peux pas déterminer si c'est au sujet de la déclaration précédente, directement et il y a quelques implicite statique modificateur sur les constantes pour commencer, ou si il se dresse sur ses propres comme une autre règle pour les constantes. Quelqu'un peut-il m'aider à éclaircir ce point?

60voto

Eric Lippert Points 300275

Mise à JOUR: Cette question a été l'objet de mon blog le 10 juin 2010. Merci pour la grande question!

pourquoi la décision de ne pas forcer constantes à utiliser le modificateur static si elles sont considérées comme statique?

Supposons que les constantes sont considérés comme statiques. Il y a trois choix possibles:

  1. Faire statique en option: "const int x..." ou "static const int x..." sont à la fois juridiques.

  2. Faire statique requis: "const int x..." est illégal, "static const int x..." est légal

  3. Faire statique illégale: "const int x..." est légal, "static const int x..." est illégal.

Votre question est: pourquoi avons-nous choisi (3)?

La conception de notes à partir de 1999 ne le dis pas; je viens de vérifier. Mais nous pouvons déduire de ce qui allait probablement par le biais de la langue concepteur de tête.

Le problème avec (1), c'est que vous avez pu lire le code qui utilise à la fois "const int x..." et "static const int y..." et puis, naturellement, demandez-vous "quelle est la différence?" Car la valeur par défaut pour les non-constante des champs et des méthodes est une "instance" moins "statique", la conclusion naturelle serait que certaines constantes sont par exemple et certains, par type, et que la conclusion serait erronée. Ce est mauvais parce que c'est trompeur.

Le problème avec (2) est que tout d'abord, il est redondant. C'est juste plus taper sans ajouter de la clarté ou de l'expressivité de la langue. Et la deuxième, je ne sais pas vous, mais personnellement, je déteste quand le compilateur me donne le message d'erreur "Vous avez oublié de dire le mot magique ici. Je sais que vous avez oublié de dire le mot magique, je suis à cent pour cent capable de comprendre que le mot magique doit y aller, mais je ne vais pas vous laisser tout le travail effectué jusqu'à ce que vous dites le mot magique".

Le problème avec (3), c'est que le développeur est nécessaire de savoir que const implique logiquement statique. Cependant, une fois que le développeur apprend ce fait, ils ont appris. C'est pas comme si c'est une idée complexe qui est difficile à comprendre.

La solution qui présente le moins de problèmes et de coûts pour l'utilisateur final est (3).

Il est intéressant de comparer et de contraste avec d'autres endroits dans la langue où les différentes décisions ont été prises.

Par exemple, de la surcharge des opérateurs sont tenus d'être à la fois publique et statique. Dans ce cas, encore une fois, nous sommes face à trois options:

  1. rendre public static facultatif,

  2. faire requis, ou

  3. rendre illégal.

Pour les opérateurs surchargés nous avons choisi (2). Depuis l'état naturel d'une méthode est privée/exemple il semble bizarre et trompeur de faire quelque chose qui ressemble à une méthode statique/invisible, comme (1) et (3) les deux nécessitent.

Pour un autre exemple, une méthode virtuelle avec la même signature qu'une méthode virtuelle dans une classe de base est censé avoir soit "nouveau" ou "ignorer" sur elle. De nouveau, trois choix.

  1. le rendre facultatif: vous pouvez le dire de nouveau, ou de remplacer, ou de rien du tout, auquel cas nous par défaut pour les nouveaux.

  2. faire requis: vous avez à dire de nouveau ou de remplacement, ou

  3. rendre illégal: on ne peut pas dire de nouveau, donc, si vous ne dites pas substituer, puis il est automatiquement de nouveau.

Dans ce cas, nous avons choisi (1) parce que ce qui fonctionne le mieux pour le caractère fragile de la classe de base de la situation de quelqu'un ajoute une méthode virtuelle d'une classe de base que vous ne réalisez pas que vous êtes maintenant primordial. Cela produit un avertissement, mais pas une erreur.

Mon point est que chacune de ces situations doit être examinée au cas par cas. Il n'y a pas beaucoup de conseils ici.

44voto

Reed Copsey Points 315315

Fondamentalement, const implique déjà statique , car la valeur ne peut pas être modifiée au moment de l'exécution. Il n'y a aucune raison pour que vous déclariez jamais une constante statique , car c'est déjà implicite, et les concepteurs de langage ont décidé de faire en sorte que la syntaxe du langage reflète cela.

Le langage de spécification dit essentiellement "Const est toujours statique, donc vous ne pouvez pas dire explicitement statique et const car il est redondant."

9voto

Adam Robinson Points 88472

Il n'est ni requis ni autorisé car il est redondant. Si tous les membres const sont statiques, seule la confusion peut résulter du fait que certains d'entre eux peuvent être spécifiés comme static et que certains ne le sont pas.

0voto

Artemix Points 1347

Une autre raison de refuser de déclarer des constantes statiques est qu'à partir de CLR point de vue, les constantes ne sont pas stockées dans la mémoire avec d'autres champs statiques du type.

Les constantes n'ont pas d'adresse de mémoire et vous ne pouvez pas obtenir une référence à la valeur de la constante (la seule exception est les constantes de chaîne). Au moment de l'exécution le type en maintenant constant définition ne sera pas chargé si d'autres statique/non membres ne sont pas référencées. Si c'est le seul type dans l'assemblée, vous pouvez même supprimer en toute sécurité de la DLL à partir du disque après la compilation.

Ainsi, les constantes sont "statiques" seulement en termes de "peut être référencé à partir de méthodes statiques'. Les constantes n'ont pas d'autres "statique" propriétés que les autres types statiques des membres de le faire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X