Déclarations de variables dans les fichiers d'en-tête - statiques ou non?

Lors de la refactorisation de certaines, #definesje suis tombé sur des déclarations similaires aux suivantes dans un fichier d'en-tête C ++:

static const unsigned int VAL = 42;
const unsigned int ANOTHER_VAL = 37;

La question est de savoir quelle différence, le cas échéant, la statique fera-t-elle? Notez que l'inclusion multiple des en-têtes n'est pas possible en raison de l' #ifndef HEADER #define HEADER #endifastuce classique (si cela compte).

La valeur statique signifie-t-elle qu'une seule copie de VALest créée, au cas où l'en-tête serait inclus par plus d'un fichier source?

Les staticmoyens qu'il y aura une copie VALpour chaque fichier source , il est inclus. Mais elle a aussi des moyens que les inclusions multiples ne seront pas donner lieu à de multiples définitions de VALqui entrent en collision au moment de la liaison. En C, sans le, staticvous devez vous assurer qu'un seul fichier source est défini VALtandis que les autres fichiers source le déclarent extern. Habituellement, on le ferait en le définissant (éventuellement avec un initialiseur) dans un fichier source et en plaçant la externdéclaration dans un fichier d'en-tête.

static les variables au niveau global ne sont visibles que dans leur propre fichier source, qu'elles y soient parvenues via une inclusion ou qu'elles aient été dans le fichier principal.

Note de l'éditeur: en C ++, les constobjets sans mots-clés staticni externdans leur déclaration le sont implicitement static.

Les balises staticet des externvariables de portée fichier déterminent si elles sont accessibles dans d'autres unités de traduction (c.-à-d. Autres .cou .cppfichiers).

• staticdonne le lien interne variable, en le cachant des autres unités de traduction. Cependant, les variables avec un lien interne peuvent être définies dans plusieurs unités de traduction.

• externdonne le lien externe variable, le rendant visible aux autres unités de traduction. Cela signifie généralement que la variable ne doit être définie que dans une seule unité de traduction.

La valeur par défaut (lorsque vous ne spécifiez pas staticou extern) est l'un de ces domaines dans lesquels C et C ++ diffèrent.

• En C, les variables de portée fichier sont extern(liaison externe) par défaut. Si vous utilisez C, VALest staticet ANOTHER_VALest extern.

• En C ++, les variables de portée fichier sont static(liaison interne) par défaut si elles le sont const, et externpar défaut si elles ne le sont pas. Si vous utilisez C ++, les deux VALet ANOTHER_VALsont static.

À partir d'un brouillon de la spécification C :

6.2.2 Liens d'identificateurs ... -5- Si la déclaration d'un identificateur pour une fonction n'a pas de spécificateur de classe de stockage, son lien est déterminé exactement comme s'il avait été déclaré avec le spécificateur de classe de stockage extern. Si la déclaration d'un identificateur pour un objet a une portée de fichier et aucun spécificateur de classe de stockage, son lien est externe.

À partir d'un brouillon de la spécification C ++ :

7.1.1 - Spécificateurs de classe de stockage [dcl.stc] ... -6- Un nom déclaré dans une portée d'espace de noms sans spécificateur de classe de stockage a un lien externe à moins qu'il n'ait un lien interne en raison d'une déclaration précédente et à condition qu'il ne soit pas déclaré const. Les objets déclarés const et non explicitement déclarés extern ont un lien interne.

Le statique signifiera que vous obtenez une copie par fichier, mais contrairement à d'autres, il est parfaitement légal de le faire. Vous pouvez facilement tester cela avec un petit exemple de code:

test.h:

static int TEST = 0;
void test();

test1.cpp:

#include <iostream>
#include "test.h"

int main(void) {
    std::cout << &TEST << std::endl;
    test();
}

test2.cpp:

#include <iostream>
#include "test.h"

void test() {
    std::cout << &TEST << std::endl;
}

L'exécution de ceci vous donne cette sortie:

0x446020
0x446040

constles variables en C ++ ont un lien interne. Donc, l'utilisation staticn'a aucun effet.

ah

const int i = 10;

one.cpp

#include "a.h"

func()
{
   cout << i;
}

deux.cpp

#include "a.h"

func1()
{
   cout << i;
}

S'il s'agissait d'un programme C, vous obtiendrez une erreur de «définition multiple» pour i(en raison d'un lien externe).

La déclaration statique à ce niveau de code signifie que le variabel n'est visible que dans l'unité de compilation courante. Cela signifie que seul le code de ce module verra cette variable.

si vous avez un fichier d'en-tête qui déclare une variable static et que cet en-tête est inclus dans plusieurs fichiers C / CPP, alors cette variable sera "locale" pour ces modules. Il y aura N copies de cette variable pour les N endroits où l'en-tête est inclus. Ils ne sont pas du tout liés les uns aux autres. Tout code dans l'un de ces fichiers source ne fera référence qu'à la variable déclarée dans ce module.

Dans ce cas particulier, le mot-clé "statique" ne semble pas apporter de bénéfice. Il me manque peut-être quelque chose, mais cela ne semble pas avoir d'importance - je n'ai jamais rien vu de tel auparavant.

Quant à l'inlining, dans ce cas, la variable est probablement inline, mais c'est uniquement parce qu'elle est déclarée const. Le compilateur est peut- être plus susceptible d'insérer des variables statiques de module en ligne, mais cela dépend de la situation et du code en cours de compilation. Il n'y a aucune garantie que le compilateur intégrera la «statique».

Le livre C (gratuit en ligne) contient un chapitre sur les liens, qui explique plus en détail la signification de `` statique '' (bien que la bonne réponse soit déjà donnée dans d'autres commentaires): http://publications.gbdirect.co.uk/c_book /chapter4/linkage.html

Pour répondre à la question, "le statique signifie-t-il qu'une seule copie de VAL est créée, dans le cas où l'en-tête est inclus par plus d'un fichier source?" ...

NON . VAL sera toujours défini séparément dans chaque fichier qui comprend l'en-tête.

Les normes pour C et C ++ provoquent une différence dans ce cas.

En C, les variables de portée fichier sont externes par défaut. Si vous utilisez C, VAL est statique et ANOTHER_VAL est externe.

Notez que les éditeurs de liens modernes peuvent se plaindre de ANOTHER_VAL si l'en-tête est inclus dans des fichiers différents (même nom global défini deux fois), et se plaindraient certainement si ANOTHER_VAL était initialisé à une valeur différente dans un autre fichier

En C ++, les variables de portée fichier sont statiques par défaut si elles sont const et extern par défaut si elles ne le sont pas. Si vous utilisez C ++, VAL et ANOTHER_VAL sont statiques.

Vous devez également tenir compte du fait que les deux variables sont désignées const. Idéalement, le compilateur choisirait toujours d'inline ces variables et de ne pas inclure de stockage pour elles. Il existe une multitude de raisons pour lesquelles le stockage peut être alloué. Ceux auxquels je peux penser ...

• options de débogage
• adresse prise dans le dossier
• le compilateur alloue toujours le stockage (les types const complexes ne peuvent pas être facilement insérés, cela devient donc un cas particulier pour les types de base)

En supposant que ces déclarations ont une portée globale (c'est-à-dire qu'elles ne sont pas des variables membres), alors:

statique signifie «lien interne». Dans ce cas, puisqu'il est déclaré const, cela peut être optimisé / intégré par le compilateur. Si vous omettez le const, le compilateur doit allouer du stockage dans chaque unité de compilation.

En omettant statique, le lien est externe par défaut. Encore une fois, vous avez été enregistré par la const ness - le compilateur peut optimiser / utilisation en ligne. Si vous supprimez le const, vous obtiendrez une erreur de symboles multiples définis au moment de la liaison.

Vous ne pouvez pas déclarer une variable statique sans la définir également (c'est parce que les modificateurs de classe de stockage static et extern s'excluent mutuellement). Une variable statique peut être définie dans un fichier d'en-tête, mais cela ferait en sorte que chaque fichier source contenant le fichier d'en-tête ait sa propre copie privée de la variable, ce qui n'est probablement pas ce qui était prévu.

Les variables const sont par défaut statiques en C ++, mais extern C. Donc, si vous utilisez C ++, la construction à utiliser n'a aucun sens.

(7.11.6 C ++ 2003 et Apexndix C a des exemples)

Exemple de comparaison des sources de compilation / liaison en tant que programme C et C ++:

bruziuz:~/test$ cat a.c
const int b = 22;
int main(){return 0;}
bruziuz:~/test$ cat b.c
const int b=2;
bruziuz:~/test$ gcc -x c -std=c89 a.c b.c
/tmp/ccSKKIRZ.o:(.rodata+0x0): multiple definition of `b'
/tmp/ccDSd0V3.o:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status
bruziuz:~/test$ gcc -x c++ -std=c++03 a.c b.c 
bruziuz:~/test$ 
bruziuz:~/test$ gcc --version | head -n1
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609

Static empêche une autre unité de compilation d'externaliser cette variable afin que le compilateur puisse simplement "insérer" la valeur de la variable là où elle est utilisée et ne pas créer de stockage mémoire pour elle.

Dans votre deuxième exemple, le compilateur ne peut pas supposer qu'un autre fichier source ne l'externera pas, il doit donc stocker cette valeur quelque part en mémoire.

Static empêche le compilateur d'ajouter plusieurs instances. Cela devient moins important avec la protection #ifndef, mais en supposant que l'en-tête est inclus dans deux bibliothèques séparées et que l'application est liée, deux instances seraient incluses.