Version imprimable
Bonjour,
J'ai creer in fichier (.h) pour mettre tous mes constantes.
Tout va bien , jusqu'a l'ajout du ligne ci dessous :
alors la le compilateur m'insule avec :Code:static const std::string pattern("</message>") ;
error: variable `std::string MyNameSpace::pattern' has initializer but incomplete type
Quelqu'un a une idée de koi s'agit il ?
Merci en avance
Salut,
Il manque sans doute :
Ou bien ?Code:#include <string>
MAT.
Salut,
De fait, il est plus que fort vraissemblable que tu aies oublié d'inclure le fichier <string>, car c'est le message typiquement obtenu avec ce genre d'oubli...
Par contre, faut il rappeler que:
- Les variables globales, de manière générale, c'est mal... fussent-elles statiques
- L'initialisation d'une variable statique ne devrait être présente que dans un seul fichier d'implémentation, et donc que tu devrais diviser ton code en
fichier.hfichier.cppCode:static const std::string pattern;
Code:
2
:question:
Ce serait pas plutot:
.hpp:
.cpp:Code:
2
3
Je suis presque sur que déclarer static une variable globale n'est pas permis (c'est de toutes façons illogique).Code:const std::string maclasse::pattern("message");
Je ne vois absolument pas pourquoi il ne serait pas permis de déclarer une variable statique (même constante) en dehors d'une classe...Citation:
Envoyé par zais_ethael
Je suis d'accord avec toi que c'est la pire des manière qui puisse être envisagée, et que, dans l'idéal, ce devrait au moins être ailleurs que dans l'espace de nommage global, mais il n'y a strictement rien qui l'interdise :D
Maintenant, que tu la déclare dans l'espace de nommage global, dans un espace de nommage particulier, ou au sein d'une classe, cela ne changera strictement rien au problème posé :roll:: cela n'influera que sur la portée dans laquelle cette variable sera accessible :D
hmmm, variable, dites vous, mais il y a ecrit "const" dedans.
c'est loin d'etre une variabe globale ici, il s'agit bien d'une constante.
Le seul defaut c'est qu'elle va etre dupliquée dans toute les unités qui incluent, pas de quoi fouetter un chat.
ca c'est faux. le mot clé static devrait alors etre remplacé par extern.Citation:
Envoyé par koala01
Lio,
Mais ça montre un défaut de conception, et des chats ont été fouettés pour moins que ça. :)Citation:
Envoyé par screetch
Que ce soit constantes ou variables globales, leur place n'est pas dans un .h
non ca ne montre pat un defaut de conception du tout. le fait de mettre dans un header permet d'etre sur que toute les unites ont la meme valeur.
les constantes ont interet a etre partagées lorsqu'elles sont physiquement partagées entre plusieurs fichiers. il n'y a rien de mauvais la dedans.
ou alors serais tu du genre de ceux que l'on pends car ils ont copié collé "</message>" a plusieurs endroits dans le code ?
Dans tous les cas là y'a pendaison pour ne pas avoir remanié et encapsulé la sérialisation de la hiérarchie de messages, ce qui aurait eu pour conséquence de n'avoir "</message>" (ou une constante) que dans une seule unité de compilation... 8-)Citation:
Envoyé par screetch
MAT.
A mon sens, les variables globales posent deux problèmes :Citation:
Envoyé par koala01
- Elles polluent l'espace de nom avec une variable dont on ne sait pas trop que faire, sauf le bout de code considéré. Si la variable est dans un espace de nom non global, ce défaut est grandement réduit.
- Elles peuvent être accédée en lecture et écriture de n'importe où, la responsabilité de cette variable est totalement diffuse, et elles rendent par là même le code difficile à suivre.
Dans le cas de constantes, le second problème n'existe pas, aussi je n'ai pas de réticences à utiliser des constantes globales.
il existe des tonnes de cas ou ce joli principe est violé. quand on definit un enum, c'est en general des variables globales const (comme celle vue plus haut) interrogées depuis plusieurs unités de compilations. la seule difference c'est le type qui devient un entier.Citation:
Envoyé par Mat007
quand je definis un enum visible je fais exactement la meme chose que vu plus haut.
c'est gentil les beaux principes de genie logiciels lus dans des livres mais les repeter sans reflechir ne fait pas avancer le schmilblick
un exemple concret de cas ou je peux vouloir partager une chaine "</message>" entre plusieurs unités de compilation : j'ecris un module capable de streamer et destreamer des objets vers un flux XML. dans ce cas je vais separer la lecture et l'ecriture dans deux fichiers distincts. Mais je souhaite qu'elles restent a jour si je decide de renommer le nom d'une balise. donc je vais ecrire un fichier header balises.h qui definira les balises, lesquels seront incluses a la fois pour la lecture et l'ecriture.
Une constante est une donnée comme une autre, et en général les données on les encapsule.Citation:
Envoyé par screetch
En terme de développement objet on est quand même supposé regrouper les données derrière les traitements qui s'y applique.
Je ne vois pas bien pourquoi, sous prétexte qu'elles sont constantes, ces données n'auraient pas besoin d'être encapsulées.
Je ne fais jamais d'enum, je me suis aperçu que je pouvais toujours obtenir quelque chose de 'mieux', encore une fois en encapsulant derrière des traitements.Citation:
Envoyé par screetch
Je connais les cas 'classiques' de leur utilisation (définir un niveau de log, numéroter des messages réseau, etc..) mais pour chacun il y a des alternatives plus élégantes.
(je ne parle bien sûr pas du truc de définir une constante dans une énumération pour pouvoir l'utiliser comme taille d'un tableau)
J'ai pourtant l'impression de réfléchir, d'essayer des choses nouvelles, de conserver ce qui fonctionne (mieux qu'avant) et de les appliquer tous les jours.Citation:
Envoyé par screetch
Mais pas de problème, si ta méthode de fonctionner te permet de faire du code correct, sans bug, évolutif, dans les délais et surtout qui te satisfasse, c'est je pense l'essentiel.
(c'est pas du tout ironique, je le pense vraiment)
Donc là soit tu sépares une classe en deux fichiers, ce dont je doute un peu tout de même, soit tu pars de deux classes distinctes pour la sérialisation et la désérialisation desquelles tu factorises une chaine de caractères dans une constante.Citation:
Envoyé par screetch
C'est bien de factoriser les données, mais c'est s'arrêter en route : qui dit données dit traitements qui les utilisent et il est donc très vraisemblablement possible de poursuivre plus loin la factorisation pour tendre vers une encapsulation de "message" derrière des méthodes d'une classe unique.
D'ailleurs n'est-on pas supposé réfléchir avant tout en terme de traitements (qui définissent les interfaces publiques) plutôt qu'en terme de données (qui sont encapsulées) ?
C'est en tous cas ce que j'applique tous les jours, et qui me convient à moi.
Bref...
Bien sûr, que PI soit dans un Math.h central ou qu'avant chaque utilisation il soit recalculé dans une constante par un acos(-1), on s'en fout un peu...
Les constantes que je critique sont surtout celles qui sont en dehors d'une classe mais qui font tout de même partie d'une interface (au sens large) pour l'utilisateur, pour moi ça reste des données mal encapsulées.
MAT.
ce n'est pas parce qu'une constante est dans un .h qu'elle est publiée. un header C++ peut servir a factoriser des declarations entre deux fichiers sources C++, etre inclus uniquement dans ces deux cpp. a vouloir l'encapsuler dans une classe tu risques de la rendre publique au final, ce qui est l'inverse de ce qui est recherché.Citation:
Envoyé par Mat007
un exemple : lorsque tu crées un parser avec flex et bison, bison genere un fichier .h inclus par flex et bison pour partager les tokens. ce n'est pas pour cela que tu vas fournir aux clients du parser la liste des tokens :)