ISO C++ forbids declaration

Je developpe parallelement un projet sous win et linux avec codeblocks.

Hier, j'ai voulu compiler ma version linux sous win et j'ai eu le message suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

-------------- Build: Debug in cfsdproject --------------- Compiling: cfsdproject.cpp In file included from D:\Programming - New\cfsdproject\/iopack/command.h:10, from D:\Programming - New\cfsdproject\/iopack/terminal.h:13, from D:\Programming - New\cfsdproject\/cfsdproject.h:8, from D:\Programming - New\cfsdproject\cfsdproject.cpp:5: D:\Programming - New\cfsdproject\/iopack/fileparser.h:38: error: ISO C++ forbids declaration of `Polygon' with no type D:\Programming - New\cfsdproject\/iopack/fileparser.h:38: error: expected `;' before '*' token Process terminated with status 1 (0 minutes, 1 seconds) 2 errors, 0 warnings

---

J'ai beau verifier le code source il n'y a apparement aucun soucis.
J'ai reinstalle codeblocks, j'ai remonte le projet fichier par fichier... Mais toujours la meme erreur.
J'ai recompile le meme code sous linux et je n'ai eu aucune erreur.

Je n'ai jamais eu un probleme de ce genre, alors si quelqu'un a une piste :oops:

Il nous faudrait voir la partie du code qui génère l'erreur.

Sio,

Comme dirait Emmanuel dans la section C, c'est manifestement l'erreur là, tu dois bien voir quand même, ligne 142. :)

Je rappelle que le meme code se compile sans aucune erreur sous linux!

Code:

---

1 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 38 39 40 41 42

#ifndef POLYGONH #define POLYGONH //--------------------------------------------------------------------------- #include <ostream> #include <string> //--------------------------------------------------------------------------- #include "../../../upack/char/unicode.h" //--------------------------------------------------------------------------- class Polygon { public: std::string label; int shape; double x0; double y0; double lx; double ly;   Polygon(); void operator=(Polygon& ); }; //--------------------------------------------------------------------------- inline std::ostream& operator<<(std::ostream& out,Polygon* P) { out << P->label << ARR; if(P->shape == 0) out << "Square("; else out << "Rectangle("; out << P->x0; out << "," << P->y0; if(P->shape == 0) out << "," << P->lx << ")"; else out << "," << P->lx << "," << P->ly << ")"; out << std::endl; return out; } //--------------------------------------------------------------------------- #endif //---------------------------------------------------------------------------

---

C'est pas ce fichier où il y a une erreur plutôt ? cfsdproject.cpp

Salut,

Généralement, une erreur "iso vobits declaration of '...' with no type" signifie, tout simplement que le compilateur ne trouve pas la définition du type cité pour l'unité de compilation en cours de traitement.

La raison principale est généralement qu'un fichier d'en-tête n'est pas inclus correctement, ou qu'un type n'a pas pu etre défini correctement, du fait d'un autre erreur

Le compilateur pousse la gentillesse jusqu'à t'indiquer ce qui ne va pas:

• à la ligne 5 de cfsdproject.cpp, tu inclus cfsdproject.h, or,
• à la ligne 8 de cfsdproject.h, tu inclus terminal.h, qui, lui-même
• inclus command.h à la ligne 13, et,
• à la ligne 10 de ce fichier (command.h), il semblerait que tu essaye de déclarer une variable dont le type (Polygon) n'est pas connu du compilateur.

Visiblement, tu as donc oublié d'inclure le fichier polygon.h dans command.h, étant donné qu'il ne te dis même pas que le fichier n'est pas trouvé ;)

Un petit conseil en passant:

Méfie toi des chemins relatifs lors de l'inclusion de fichiers d'en-tête appartenant à une bibliothèque externe (car je présume que
#include "../../../upack/char/unicode.h" fait appel à un fichier de bibliothèque externe :question:) pour la simple et bonne raison que tu ne peut en aucun cas préjuger du fait que le chemin sera identique sur n'importe quel système.

Cela te permettra de gagner en souplesse au niveau du système utilisé pour la compilation ;)

L'idéal étant de définir, dans les options de compilation, un chemin de base certain comme étant un dossier dans lequel on trouvera des fichiers d'en-tête (par exemple c:\mingw\include\upack ou /usr/include/upack) et de donner le chemin relatif à partir de ce dossier "de base" (donc simplement char/unicode.h)

Pour indiquer un dossier comme devant être utilisé pour rechercher les fichiers inclus, il s'agit généralement de fournir un argument -Idossier à la commande de compilation ;) (la plupart des EDI permettent en outre de spécifier ces dossiers dans les options de compilation ;))

Salut,

Au passage un opérateur d'affectation s'écrit :

Code:

---

Polygon& operator=(Polygon& );

---

MAT.

Le fichier qui contient l'erreur est fileparser.h

Code:

---

1 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

#ifndef FILEPARSERH #define FILEPARSERH //--------------------------------------------------------------------------- #include <ostream> #include <ctype.h> #include <stdlib.h> #include "cdproblem.h" #include "keywords.h" //--------------------------------------------------------------------------- class FileParser { public: ... CDProblem* fpP; Polygon *nPolygon; ... inline FileParser(string cFile) { ... } inline ~FileParser() { ... } ... }; //--------------------------------------------------------------------------- #endif //---------------------------------------------------------------------------

---

Le header "cdproblem.h" contient l'include de "domain.h" qui contient l'include de "geometrylist.h" qui contient l'include de "polygon.h"

Meme lorsque j'avais mis l'include de polygon.h ca n'avais rien change

L'ensemble du projet contient plus de 60 classes une centaine de fichiers que j'ai organise sous forme de pack.
Et donc #include "../../../upack/char/unicode.h" fais reference a une biblio interne que j'ai moi meme developpe.

J'imagine que tu as tenté le rebuild all. Je vois pas sinon.

J'ai meme recree le projet et ajoute tous les fichiers un a un :cry:

Ce n'est pas un problème d'inclusion circulaire qui, d'une manière ou d'une autre, bloque la déclaration de Polygon?

Note que si dans la déclaration d'une classe 'A', tu as un membre de type 'pointeur ou référence vers B*' (et non pas 'B tout court') et que tu n'as pas de fonction inline qui utilise une variable de type 'B', alors tu peux te contenter d'une déclaration avancée (forward declaration), ce qui réduit les dépendances entre les fichiers et peut également réduire le temps de compilation.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class B; // Pas besoin de #include "B.h"   class A { public: B GetB() const; void SetB(B theB);   private: B* m_pB; };

---

Remplace 'A' par 'FileParser' et 'B' par 'Polygon' dans mon exemple, et essaye déjà cela pour voir si cela règle ton problème. Si oui, alors tu dois chercher à comprendre pourquoi le compilateur ne 'voit' pas la déclaration de Polygon. Si non, alors... essaye autre chose!

Bon courage!

Carl

Citation:

---

Envoyé par Mat007

Au passage un opérateur d'affectation s'écrit :

Code:

---

Polygon& operator=(Polygon& );

---

---

C'est pas plutot:

Code:

---

1 2	Polygon& operator=(const Polygon&);

---

Parceque bon.... si l'affectation modifie l'objet source, c'est à se tirer une balle au débugage ! :D

Pour ce qui est de la compilation, si ca compile sous un autre système, il n'y a pas de raison que ce soit une inclusion circulaire....
Néanmoins, je chercherai (l'IDE que tu utilises doit bien avoir cette options) toutes les définitions éventuelles de POLYGONH (des fois qu'un fichier fasse un #define POLYGONH malencontreux). Pour éviter ca, tu peux t'amuser à mettre des '_' (genre: _H_POLYGON_).

En même temps, comme dit 5hdumatin.... Si tu n'as que des Polygon* ou Polygon& ... il te suffit d'une prédéclaration genre:

Code:

---

1 2	class Polygon;

---

avant.

La règle c'est de faire le moins d'includes possibles dans .h...

Par contre, son exemple ne marche pas (utilisation de la taille de B pour get/set), il manque des pointeurs:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class B; // Pas besoin de #include "B.h" class A { public: B* GetB() const; void SetB(B* theB); private: B* m_pB; };

---

Ca évite les recopies....

Citation:

---

Envoyé par nicroman

C'est pas plutot:

Code:

---

1 2	Polygon& operator=(const Polygon&);

---

---

Bien vu ! 8-)

MAT.

Citation:

---

Code:

---

B* GetB() const;

---

---

Pas sûr.
Ça peut suffire dans certaines circonstances, mais dans d'autres, ceci est plus approprié:

Code:

---

1 2	B * GetB(); const B * GetB() const;

---

Mon exemple fonctionne, tu n'as pas besoin de la taille de l'objet pour le déclarer dans un interface publique.

Aussi bizarre que cela puisse paraitre, j'ai remplacé Polygon par Poly et ça marche 8O
Pour ce faire j'ai utilisé la fonction remplacer dans fichier de l'IDE!!! Donc ca ne vient pas de mon code 8O

Merci pour tous vos conseils.
Concernant la surcharge const est un oubli de ma part, mais sinon ca marche dans les deux cas :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

void operator=(const Polygon& p) { this.a = p.a; //ou b = p.b; } <=> Polygon& operator=(const Polygon& p) { this.a = p.a; //ou b = p.b;   return *this; }

---

Citation:

---

Envoyé par inddzen

Aussi bizarre que cela puisse paraitre, j'ai remplacé Polygon par Poly et ça marche 8O

---

Il y a une fonction système windows qui s'appelle 'Polygon'...
Dans wingdi.h, ligne 4203 très précisément.

C'est balot hein ! :?

edit : la solution est sans doute d'utiliser un namespace, vu que Microsoft n'en utilise bien sûr pas...

MAT.

Citation:

---

Envoyé par inddzen

Concernant la surcharge const est un oubli de ma part, mais sinon ca marche dans les deux cas (...)

---

Sauf que ça, ça ne compile pas si tu ne renvoies pas *this :

Code:

---

1 2	Polygon p1, p2, p3; p1 = p2 = p3;

---

MAT.