À l'aide de consts dans les 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 confond de rechercher l'utilisation dans les 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):

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 qu'elle fait un peu plus de sens parce que constantes sont considérés comme des membres statiques, mais le reste de la phrase est un peu surprenant pour moi. Pourquoi est-ce que 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?

À la recherche à 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?

  • Peut-être qu'ils ont choisi de ne pas permettre à statique, car elle pourrait conduire à la confusion: quelqu'un va voir "static const foo..." croient, à tort, que statique en fait, fait une différence, ce qui implique que vous pouvez le supprimer et en quelque sorte un non-static const.
  • Vous obtenez un très décent compilateur message d'erreur lorsque vous essayez d'utiliser static et const ensemble. Je pense que c'est assez bon.
InformationsquelleAutor Nick Larsen | 2010-04-13
  1. 43

    Fondamentalement, const implique statique déjà, depuis la valeur ne peut pas être modifiée lors de l'exécution. Il n'y a aucune raison pour vous de toujours déclarer static const, puisque c'est déjà implicite, et la langue de créateurs ont décidé de faire de la syntaxe de la langue reflètent.

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

    • Si c'est le cas, alors pourquoi ils vous permettent d'utiliser explicitement privé sur à peu près tout dans la langue?
    • L'ajout de privé ne suggère pas une signification différente. Ici, si le permis "variable const" et "static const variable", cela donnerait à penser qu'il y avait des non-static const options. Privé ne définit pas le stockage d'une variable, mais il est plus d'un décorateur décrivant c'est accessibilité - l'ajout ou la suppression il ne change pas vraiment de sens, mais ajoute un élément descriptif, le type.
    • En permettant privé à ajouter ou à gauche suggère qu'il y a non-membre privé d'options, il y a des. 🙂
    • Je pense que je commence à voir le point, mais il est un peu contradictoire pour mon utilisation normale de spécifier explicitement à peu près tout. J'aurais probablement préconisé une sorte d'avertissement du compilateur ou de quelque chose lors de la tentative de ne pas préciser une constante statique.
    • +1. Privée est tout simplement le par défaut accessibilité modificateur pour un membre de la classe. static n'est pas la valeur par défaut pour les constantes, c'est la seule option.
    • Auriez-vous l'avocat de décoration de tous les paramètres de la fonction comme étant passés par valeur (comme VB.NET le fait pour les auto-généré signatures)?
    • en sortant du modificateur d'accès signifie différentes choses dans differrent contextes. La valeur par défaut n'est pas toujours privé. Il peut être interne. Le const n'est jamais associé à une instance. Comment cela fonctionnerait-il? Je dirais que c'était très source de confusion si vous pouviez faire static const, ce qui signifierait que vous pourriez avoir un exemple constant en tant que bien, mais alors je suppose que si vous avez un c++ arrière-plan que vous pouvez lire const en readonly (aka inscriptible une seule fois) et puis tout à coup instanceness de sens. En C#, cependant const est constante et readonly est presque en lecture seule :p

    InformationsquelleAutor Reed Copsey
  2. 60

    Mise à JOUR: Cette question a fait 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. Rendre statique facultatif: "const int x..." ou "static const int x..." sont à la fois juridiques.

    2. Rendre statique nécessaire: "const int x..." est illégal, "static const int x..." est légal

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

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

    Les design 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. de 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. de 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 généraux ici.

    • J'aime votre point de vue sur statique étant un "mot magique" dans ce cas. Je ne pense pas que c'est suffisant pour faire pencher la balance pour moi, cependant, l'option 1 serait encore plus confuse, et après tous les commentaires dans ce fil, je peux comprendre le raisonnement de 3. L'inverse de cette situation, où le compilateur ne lève une erreur si j'avais essayé de faire une constante statique, aurait laissé moi avec des questions similaires.
    • +1 pour l'autorité, et l'utilisation de "mot magique". Pas forcément dans cet ordre! 😉
    • En provenance du blog: c'est peut-être juste moi, mais je trouve que ne pas avoir besoin de statique juste me confond. Si je ne vois pas le mot statique, alors je suppose que c'est une variable d'instance. Cela n'aide pas que vous pouvez accéder à la manière de l'intérieur de la classe (ce.MyConstant ou MyClassName.MyConstant). De plus, je pense que le point de langages à typage statique était de faire plus de taper sans ajouter de l'expressivité ou de clarté 😉 @Adam Robinson: vous avez Sûrement signifie utilisation de l' pas l'utilisation de 😉
    • Profitez de Yodaspeak souvent je fais.
    InformationsquelleAutor Eric Lippert
  3. 9

    Il n'est pas requis ou permis parce que c'est redondant. Si tous les const membres sont statiques, alors seulement la confusion peut naître que de permettre certains de leur être spécifié en tant que static et certains d'entre eux de ne pas être.

    • Mais c'était ma question, pourquoi ne pas tous les forcer à être statique?
    • Mais vous pouvez require le mot-clé static, au lieu d'exiger de son absence.
    • Car il n'y a aucun moyen pour eux pas pour être statique. Pourquoi exiger un redondante terme?
    • C'est un bon point, mais en laissant de très descriptif termes est quelque chose que je considère la confusion (...comme je l'ai fait 🙂 ).
    • Si vous êtes en train de dire que tout ce qui est "très descriptive" devraient être tenus, pourquoi ne pas exiger readonly sur la variable ainsi?
    • readonly et const sont différents, mais il n'est pas de me laisser poster mon commentaire... non, je ne précisez pas que vous devez passer les choses par leur valeur, mais en passant par valeur ou par référence n'apparaît pas d'emblée à la pause toutes les autres règles de la langue.
    • Il n'a pas enfreint les règles de la langue; vous avez déclaré que votre objection est que c'est en laissant de côté "descriptif" de l'information, mais le passage par valeur est descriptive, comme c'est le marquage de la constante comme étant en lecture seule; ils sont également tout aussi superflue que le marquage d'une constante static. Si vous savez ce que const à-dire dans C#, puis comment il peut-être même d'enfreindre les règles de la langue?
    • En spécifiant un const sans modificateur static, il semble briser d'autres règles de la langue lorsqu'utilisé dans une méthode statique parce que vous ne pouvez pas normalement appel non-statiques, les champs de méthodes statiques. Il apparaît lors de la statique n'est pas explicitement spécifié. Je dis qu'il est très descriptif. Et vous avez raison, si je savais ce que const signifiait, il n'apparaît pas à briser toutes les règles.

    InformationsquelleAutor Adam Robinson
  4. 0

    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 de type statique membres de faire.

    InformationsquelleAutor Artemix