Discussion :

[hydrolyre]

Bonjour,

J'ai un problème de compilation avec Dev-c++
J'ai un fichier "Ma_Classe.cpp" qui a besion du fichier "Etat_De_Ma_Classe.cpp" et en particulier la classe 'Rect'.

Etat_De_Ma_Classe.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
class Rect : public Etat_Possible//Pour mettre en place le DP par états.
{
...
};

Ma_Classe.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Ma_Classe::Ma_Classe( const int & a, const int & b)
{//Constructeur 2 arguments.
Mon_Etat = new Rect( a, b );
}

Le problème c'est que le compilateur me dit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
'Rect' has not been declared

Alors j'ai ajouté une déclaration de ma classe ( class Rect; ).
Et j'obtient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
invalid use of undefined type 'struct Rect' 
forward declaration of 'struct Rect' 
//Rect est un des états possible de 'Ma_Classe'.

Je me suis demandé si l'inclusion du fichier se faisait correctement alors j'ai copier/coller le code source de 'Rect' dans le fichier 'Ma_Classe.cpp" et mon super compilo me regarde en souriant et me nargue...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
redefinition of 'class Rect' 
previous definition of 'class Rect' //Définition de "Etat_De_Ma_Classe.cpp"
confused by earlier errors, bailing out

Donc l'inclusion se fait correctement, alors pourquoi mon compilo n'est pas capable de faire le linkage( si c'est le bon mot )?


Est-ce quelqu'un sait pourquoi mon compilo est si méchant avec moi?


PS : Il n'y a pas d'erreur de syntaxe et je suis protégé de l'inclusion multiple.

[jfouche]

Salut

Etat_De_Ma_Classe.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class Rect : public Etat_Possible//Pour mettre en place le DP par états.
{
...
};

J'aurai mis ça dans un .h plutôt.

De plus, est ce une erreur de link ou de compilation (fournis ici la ligne complete de ton compilateur indiquant l'erreur).
--
Jérémie

[hydrolyre]

Oups, c'est déjà dans un .hpp
Mais ça ne change rien, si?

Le ligne de l'erreur est celle qui est dans le constructeur de Ma_Classe, je l'ai mise dans le 1er message.
Si c'est le rapport d'erreur que tu veux, à mon grand regret je n'ai rien d'autre que ce que j'ai déjà ecrit

[koala01]

Salut,

Oups, c'est déjà dans un .hpp
Mais ça ne change rien, si?

Ca change tout
En C++, il existe une règle absolue connue sous le nom de one definition rule qui peut s'exprimer en français sous les terme simple de "il ne peut y avoir qu'une seule définition de chaque chose"...

C'est à cause de cette règle et du fonctionnement du complateur que nous faisons la distinction entre les fichiers d'en-tête (utilisant souvent l'extension *.h, *.hpp, *.hxx , *.hh voir, rien du tout pour les fichiers fournis par le standard) et les fichiers d'implémentation (utilisant l'extensions *.cpp, *.cc,*.cxx ou C (majuscule, mais si le système de fichier est sensible à la casse uniquement))

Mais cela implique qu'il faille mettre la bonne chose au bon endroit...

Ainsi, dans un fichier d'en-tête, on peut trouver:

1. des gardes anti inclusions multiples (#ifndef TRUC_HPP#define TRUC_HPP #endif // TRUC_HPP)
2. #des directives préprocesseur d'inclusion de fichier d'en-tête (#include <nom_fichier> ou #include "nom_fichier")
3. les autres directives préprocesseur
4. des déclaration anticipées de classes ou de structure
5. des déclarations de fonctions libres
6. des déclarations de variables globales (même s'il vaut mieux les éviter)
7. des définitions de types personnalisés (classes, structures, énumérations, unions, typedef)

Le (3) permet juste au compilateur de savoir qu'il existe un type du nom de la classe ou de la structure et l'empêche donc de se plaindre quand il croise le type en question, pour autant qu'il ne doive ni connaitre la taille que cela représente en mémoire (c'est à dire que nous n'utilisons le nom du type que sous la forme de référence ou de pointeur) ni connaitre le contenu du type (c'est à dire que nous n'essayons pas d'accéder à un membre ou à une fonction membre du type en question).

Dés que le compilateur a besoin de connaitre la taille utilisée en mémoire par un type (c'est à dire qu'il doit manipuler une instance de ce type) ou qu'il doit accéder à son contenu (qu'on essaye d'invoquer une de ses fonctions membres ou d'accéder à l'un de ses membres), il doit disposer de la définition du type en question.

Le (6) se distingue du (3) par le fait qu'une définition de type fournit "le corps" de ce type: valeur énumérées pour les énumération, champs pour les unions, membres et fonctions membres pour les classes et les structure, équivalence pour les typedefs...

Il est obligatoire que le compilateur en dispose dés qu'il doit connaitre la taille que le type utilise en mémoire ou dés qu'il s'agit d'accéder à son contenu

Dans un fichier d'implémentation (*.cpp), on peut trouver

1. des directives préprocesseurs (dont les directives d'inclusion)
2. des initialisations de variables globales (le fait de leur donner une valeur initiale)
3. des initialisation des membres statiques de classes ou de structures(le fait de leur donner une valeur initiale)
4. des définitions (implémentation) de fonctions et de fonctions membres de classes ou de structures

Il existe des exceptions pour

1. les définitions de fonctions inline
2. les définitions de fonction template
3. les définition de fonctions membres de classes ou de structures template
4. les initialisation de membres statiques de structures ou de classes template

qui devront se retrouver, de manière directe ou indirecte, dans un fichier d'en-tête afin que le compilateur soit en mesure de recréer le code "binaire" correspondant à tout moment.

Mais, en aucun cas, il ne faut essayer d'inclure un fichier d'implémentation, ni dans un autre fichier d'implémentation, ni (et encore moins) dans un fichier d'en-tête...

[EDIT]Au passage, le développement de DevC++ est arrêté maintenant depuis plusieurs années...

Quelques irréductibles continuent bien à maintenir tant bien que mal les DevPacks, mais cela risque aussi de s'arrêter progressivement

Si ton souhait est d'avoir un EDI gratuit et léger, je te conseillerais fortement de te tourner vers Code::Blocks[/EDIT]

[hydrolyre]

Finalement je suis retourné à l'ancienne version ( qui est, paradoxalement, identique ) et ça compile masi je saurai jamais ce qui c'est passé