Version imprimable
Pour ne pas polluer ce thread,
http://www.developpez.net/forums/sho...d.php?t=501525
je poste dans un nouveau
Ma question est pourquoi?Citation:
Appelé depuis un template non exporté (défini dans un en-tête), ça a pour seule utilité d'avoir un comportement indéfini.Citation:
Envoyé par Emmanuel Deloget
Citation:
Envoyé par corrector
Lorsque le compilateur rencontre un namespace anonyme, il génère un nom unique pour tous les identifiants déclarés (et définis) dans ce namespace. Cela a pour effet de les rendre "statique au module" (pour simplifier; en fait, tout ce qui est dans un namespace anonyme a un linkage interne, tel que défini par la norme en 3.5 §2) en cours de compilation. Au lieu d'écrire :Citation:
Envoyé par corrector
Il est préférable d'écrire :Code:
2
3
4
(cf C++ Annotation, §3.7.1.2;)Code:
2
3
4
5
6
7
Le standard dit explicitement en section 7.3.1.1 §2 :
Selon moi, on peut appliquer la même idée aux autres déclarations (fonctions et classes).Citation:
The use of the static keyword is deprecated when declaring objects in a namespace scope, the unnamed namespace provides a superior alternative.
J'aimerais bien savoir pourquoi aussi. Selon mon interprétation, le comportement est complètement défini, même si il peut y avoir quelques subtilités.Citation:
Envoyé par Mongaulois
merci de la réponse.
Ca rejoins bien la faq
http://cpp.developpez.com/faq/cpp/?p...ESPACE_anonyme
Citation:
Envoyé par Emmanuel Deloget
ca veut dire que cela ne peut etre utilisé que dans un .cpp?Citation:
Envoyé par faq c++
Salut,Citation:
Envoyé par Mongaulois
Un header est inclu via une instruction préprocesseur, donc on peut le considérer dans le fichier cpp.
Par contre, même si le namespace est dans le header, quand on en modifie l'une des variables dans le cpp, ca ne change pas cette variable dans les autres cpp.
Ex:
Code:
2
3
4
5
6
7
8
9
10
Code:
2
3
4
5
6
7
Code:
2
3
4
5
6
7
8
9
10
11
Dans l'exemple, on voit bien que message n'est pas modifié.
(Mettons l'aspect "template" de coté, il ne sert à rien ici.)Citation:
Envoyé par Mongaulois
Soit le programme :
Ce programme (complet) a un comportement indéfini, parce que la définition de multiply_defined() viole l'ODR (One Definition Rule) : multiply_defined() est définie deux fois, et les deux définitions ne correspondent pas, en effet :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25Header.hpp : namespace { // espace référentiel anonyme void rien_anon() { } } static void rien_static() { } inline void multiply_defined() { rien_anon(); // comportement indéfini rien_static(); // comportement indéfini } Toto.cpp : #include "Header.hpp" Main.cpp : #include "Header.hpp" int main() { }
Si on regarde la définition d'un espace référentiel anonyme, ceci équivaut à :
On voit que multiply_defined() est défini deux fois comme appelant des fonctions différentes.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38Toto.cpp : namespace __anon_namespace_Toto_cpp {} using namespace __anon_namespace_Toto_cpp; namespace __anon_namespace_Toto_cpp { void rien_anon() { } } static void rien_static() { // (1) } inline void multiply_defined() { rien_anon(); // appel de __anon_namespace_Toto_cpp::rien_anon() rien_static(); // appel de (1) } Main.cpp : namespace __anon_namespace_Main_cpp {} using namespace __anon_namespace_Main_cpp; namespace __anon_namespace_Main_cpp { void rien_anon() { } } static void rien_static() { // (2) } inline void multiply_defined() { rien_anon(); // appel de __anon_namespace_Main_cpp::rien_anon() rien_static(); // appel de (2) } int main() { }
Sauf que le linkage peut rester externe. Voir la note sur la même page de la norme :Citation:
Envoyé par Emmanuel Deloget
Ca peut avoir une importance en ce que du coup, une telle fonction peut être utilisée en tant que template nontype parameter.Citation:
Although entities in an unnamed namespace might have external linkage, they are effectively qualified by a name unique to their translation unit and therefore can never be seen from any other translation unit.
Pour la question initiale, je pense que Corrector fait référence au point suivant :
Citation:
Envoyé par Le standard 14.6.4.1/7
Citation:
Envoyé par Le standard 3.2/5
donc c'est bien indéfinie?
Formellement, je dirais oui.Citation:
Envoyé par Mongaulois
Par contre, je ne sais pas si avec les compilateurs classiques, ça ne marche pas quand même. Après tout, ces fonctions, bien que différentes, font la même chose, et je ne serais pas surpris que ce genre de chose "tombe en marche" la plupart du temps.
Ok merci.Citation:
Envoyé par JolyLoic
Je dirais que ca "tombe en marche" parce que la fonction est inline, peut etre...
Ce que je ne comprends pas, c'est pourquoi on voudrait mettre des namespaces anonymes dans des en-têtes.
Pour avoir des variables globales localisées à une unité de traduction, qui portent toutes le même nom ?
Justement, pour avoir des variables localisées dans une UT (unité de traduction), il faut localiser leurs déclarations dans une UT.Citation:
Envoyé par Luc Hermitte
Ce qu'on met dans un en-tête va être vu par plusieurs UT (sinon, je ne vois pas l'intérêt d'utiliser un en-tête).
Pour moi, en-têtes et espaces référentiels anonymes sont antinomiques.
En fait, un tel code voudrait dire que chaque UT possède sa propre variable globale et que toutes ont le même nom.
Ce qui selon moi, ne sert pas à grand-chose, sauf à faire du accumulate-and-fire avec des variables globales dans des fonctions inline (ce qui serait un symptôme de mauvaise conception, typiquement une fonction C appelant un callback sans paramètre de contexte).
[EDIT] /!\ANNEXE
Pour ceux que ça intéresse.
http://en.wikibooks.org/wiki/More_C%...ms/Handle_Body
http://en.wikibooks.org/wiki/More_C%...s/Counted_Body
Bon j'ai enfin trouvé un exemple de namespaces anonymes dans des en-têtes dans boost!!!Citation:
Envoyé par corrector
http://www.boost.org/boost/lambda/core.hpp
https://develop.participatoryculture...d.hpp?rev=5773
et encore d'autre.
Ca as donc bien un intérêt?
Par contre en reflechissant, ce qui est indéfinie, a mon avis, est d'utiliser une fonction/variable définie dans un namespaces anonymes dans un en-tête
Bon, faisons un court test:Citation:
Envoyé par corrector
entete.h
main.cppCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
other.cppCode:
2
3
4
5
6
7
8
Résultats (ligne de commande approximative; ça fait longtemps que je n'ai pas utilisé g++):Code:
2
3
4
5
6
1) g++ main.cpp other.cpp -o mytest -DTEST1_1 : fonctionne dans tous les cas
2) g++ main.cpp other.cpp -o mytest -DTEST1_2 : fonctionne aussi
3) g++ main.cpp other.cpp -o mytest -DTEST2 : fonctionne dans tous les cas
4) g++ main.cpp other.cpp -o mytest -DTEST3 : ne compile pas, car delete_set_null() est défini deux fois.
Résultat: il est nécessaire déclarer delete_set_null() soit comme étant une fonction statique ou inline, soit dans un namespace anonyme.
Hors:
1) il est déconseillé de définir des fonctions inline; l'idéal est de laisser le compilateur choisir quelle fonction il inline.
2) static est, en C++, censé être réservé à la définition de statiques de classes. Son usage est censé être remplacé par l'utilisation de namespace anonymes.
Conclusion : les namespace anonyme ont bel et bien leur place dans les fichiers entêtes.
Maintenant, il est évident que si on déclare une variable avec un linkage static, il est interdit de l'utiliser dans deux modules différents en espérant que ce soit la même - ce n'est pas le cas.
Quand à la violation de l'ODR: std 3.2/3 dit explicitement que les fonctions inline sont définies dans chaque UT qui les utilise. De fait, le code de corrector n'est pas invalide, puisque plusieurs définitions de multiply_defined() sont créee, chacune faisant référence à ses propres fonctions "statiques". Seules les fonctions non-inline doivent respecter l'ODR (mais si on enlève inline dans l'exemple de corrector, le code ne link pas).
En ce qui concerne les templates+static, je suis assez d'accord. Le problème est par contre assez difficile à mettre en évidence.[/code]
Salut.
Merci, de ta réponse.
Va falloir que je la relise pour bien comprendre :aie:
Pourquoi?Citation:
Envoyé par Emmanuel Deloget
Principalement parce que le compilateur sait quel fonction lui sera utile d'inliner de manière à obtenir les performances maximales. Si on force l'inline d'une fonction trop longue, on risque de faire exploser la taille du code et de défaire certaines optimisations (notamment celles qui ont trait au cache de code).Citation:
Envoyé par Mongaulois
En fait, le mot clef inline est libre d'être totalement ignoré par les compilateurs. Il peut décider de mettre en inline certaines fonctions qui ne sont pas déclarée inline, et de refuser l'inlining de certaines fonctions qui sont déclarées inline.
Je ne vois pas ce que tu cherches à démontrer.Citation:
Envoyé par Emmanuel Deloget
Comprends pas. Quelle fonction delete_set_null()?Citation:
Envoyé par Emmanuel Deloget
Est-ce que tu as réellement posté le code que tu as utilisé?
Il faudrait le leur demander, à mon avis.Citation:
Envoyé par Mongaulois
Oui, en gros c'est ça.Citation:
Envoyé par Mongaulois
C'est assez curieux de définir dans un en-tête des choses qui ne peuvent pas être utilisé dans un autre en-tête.
Oui, je pensais effectivement à 3.2/5. (Je viens de le relire, dans N2315 : qu'est-ce que c'est long! Je me souvenais plus que c'était aussi indigeste - le coup du constructeur à la fin, c'est hyper-tordu.) (Ceci dit, cette clause pose quand même quelques problèmes.)Citation:
Envoyé par JolyLoic
Par contre, je ne pensais pas du tout à aller cherche dans le chapitre 14 (parce que je ne pensais aux templates). D'ailleurs, la dernière phrase de 14.6.4.1/7 que tu cites dit exactement la même chose que l'avant-avant-dernière de 3.2/5 que tu coupes : "If D is a template, ... also to dependent names at the point of instantiation (14.6.2)."