J'apprends C ++ et j'ai rencontré une variable statique (j'ai des connaissances antérieures de C89) et dans la ressource que j'utilise, ils ont déclaré une variable statique dans une classe telle que: xxx pré>
par exemple. Ce que je ne comprends pas, c'est que, puisque j'ai déjà déclaré que la variable statique est un entier dans la définition de la classe, pourquoi dois-je aussi le déclarer comme un entier en dehors de la définition de la classe? N'aurait-il pas de sens de simplement l'initialiser comme si: P>
nameHere::totalNum = 0; int main() {}
3 Réponses :
Il y a une différence entre une définition et une déclaration. Bien que la variable statique de la classe ait été déclarée, elle n'a pas été définie. Une règle de définition , explique les déclarations et les définitions et les états p>
Dans n'importe quelle unité de traduction, un modèle, un type, une fonction ou un objet ne peut avoir plus d'une définition. Certains d'entre eux peuvent avoir un nombre de déclarations. p> blockQuote>
Par conséquent, le type complet de l'objet doit être utilisé lors de la déclaration de la variable. P>
Ce serait (probablement) rendre la langue encore plus difficile à analyser (et il est déjà presque difficile d'analyser de toute façon). P>
tel qu'il est, le type de données ( Dans le cas spécifique des choses à la portée mondiale, ce ne serait pas si mal, car à la portée mondiale de tout ce que vous pouvez avoir est une série de déclarations. Cependant, à toute autre portée, les choses seraient plus difficiles (et avoir une règle à la portée mondiale, et une autre ailleurs serait en effet laid). P> int code>,
long code>,
my_class code>, peu importe) indique au compilateur que ce qu'il voit est le début de Une déclaration (laquelle, dans ce cas, est également une définition). Sans cela, le compilateur aurait une période plutôt plus difficile de trier des choses. P>
in
Vous pouvez le faire en C ++ 03 aussi. Je ne pense pas qu'il y ait eu de changement concernant l'initialisation des membres de données statiques en C ++ 11. Ce qui est nouveau, c'est que vous initialisez les membres de données non statiques au point de déclaration.
@juanchopanza, avec statique code>, vous pouvez désormais initialiser des types non intégrés là aussi longtemps que c'est un
consexpr code>.
Probablement la même raison pour laquelle nous ne pouvons pas dire
Someclass :: Somememberfunction {...} Code> Pour définir une fonction de membre.
Venez penser à cela, cela éclaircirait un peu la syntaxe et empêcherait les erreurs de Pesky qui découlent d'une typographie ou d'une spécification manquante, mais dans le cas de fonctions, au moins, il peut être utile de mettre
const Code> sur les paramètres de valeur dans la définition, mais pas la déclaration, même si je pouvais m'habituer à ce dernier si cette syntaxe était une option.
Cela compliquerait plus la grammaire. Il y a déjà une ambiguïté de déclaration / d'expression, cela le prendrait encore plus loin.
Oh, et vous devriez envisager des surcharges pour des fonctions. Pour les fonctions non surchargées, je ne vois pas pourquoi il ne serait pas travail i>, mais les surcharges le rendraient plus complexes. Qui sait, peut-être que c'était la justification des fonctions qui ne se traduisent pas le traitement et les variables ont suivi une combinaison. C'est toujours possible i> je suppose.