Bonjour moi une personne en train d'apprendre le C++ orienté objet n'arrive pas a implémenter une classe dans un fichier .h (un header) a chaque fois que je le fait il me dit que je les définis 2 fois sauf que a chaque fois je ne les mis que dans le .h (header) et que dans sont fichier source et donc je ne comprend pas si vous voulez un exemple je peux en donner si vous voulez.
Oui il faut que nous montre ton code même nos boules de cristales ne peuvent pas nous aider à voir ton code
Mais à tout hasard je dirais que tu n'as pas mis de header guards pour te protéger des inclusions multiples et/ou que tu inclus ton fichier .cpp dans ton main
Mais ce n'est qu'une supposition il faut que nous montre tout ton code
#pragma once
class FClassA
{
public:
void Adv(int HealthAA, int dgtAA)
int Att(int dgtC, int HealthEC)
int Heal(int HealthC)
private:
int Health;
int dgt;
};
//plan de l'advairsaire
class FClassE
{
public:
void Adv(string NameEE, int dgtEE)
int Att(int dgtC, int HealthEC)
int Heal(int HealthC)
private:
string Name;
int dgt;
};
Et voici le fichier source de la classe portant le même nom que le header mais avec un .cpp
#include <iostream>
#include "ClassFIGHT.h"
using namespace std;
class FClassA
{
public:
void Adv(int HealthAA, int dgtAA)
{
Health = HealthAA;
dgt = dgtAA;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
private:
int Health;
int dgt;
};
//plan de l'advairsaire
class FClassE
{
public:
void Adv(string NameEE, int dgtEE)
{
Name = NameEE;
dgt = dgtEE;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
private:
string Name;
int dgt;
};
Salut, tu as deux classes qui font la même chose, avec les même attributs et méthodes. Tu devrais en avoir une dans ton cas precis, qui portera le nom du header en question. Un header fclass.h (a la place de classfight.h) pourrait avoir cette structure:
#ifndef FCLASS_H
#define FCLASS_H
class FClass{
};
#endif
Tu dois reprendre ton cours de C++ et regarder comment on implémente les fonctions d'une classe dans le fichier .cpp
Tu as déclaré tes classes dans fichier .h et au lieu de simplement impémenter tes fonctions dans le cpp tu redéclares ta classe et tu redéclares leurs fonctions.
Puisque tu déclares ta classe à deux endroits, c'est normal que le compilateur d'indique qu'il il y a des déclarations multiples.
Tu peux supprimer tout le contenu de fichier .cpp et recommencer
Ce qu'il faut comprendre, c'est que le compilateur n'est vraiment pas "très futé". Mais bon, faut pas lui en vouloir, après tout, ce n'est qu'une suite de 1 et de 0 exécutée par une machine
On lui a donc appris à faire la différence entre la déclaration (le fait de lui indiquer qu'une classe existe) et la définition (le fait de lui indiquer "de quoi la classe se compose") d'une classe.
Si le compilateur rencontre un code proche de
class UnNomQuelconque; //remarque qu'il n'y a rien entre le nom
// et le point virugle
il a affaire à une déclarationde la classe, et s'il rencontre un code proche de
class UnNomQuelconque{
// peu importe ce qu'il y a ici
}; // remarque qu'il y a une paire d'accolade "{" et "}"
// (et tout ce qu'il y a entre les deux) entre le nom de
// la classe et le point virgule
il a affaire à une définition de la classe.
La règle est suffisamment simple pour que même le compilateur soit en mesure de la comprendre
Par la suite, on lui a fait comprendre que la règle nommée ODR (One Definition Rule ou "règle de la définition unique") s'appliquait pour les noms de classes.
Autrement dit, qu'il peut accepter sans problème d'avoir plusieurs déclarations d'une même classe, mais qu'il ne peut accepter d'avoir que une et une seule définition de cette classe.
Et c'est tout à fait normal, car, si le fait de lui donner plusieurs déclarations de la classe peut être considéré comme "un simple rappel" que la classe existe, le fait de lui donner plusieurs définitions de la classe va rapidement mettre le compilateur "dans la panade".
Parce que cela impliquerait que le compilateur devra -- tôt ou tard -- choisir la définition qu'il utilisera pour travailler. Et comme il est pas fut fut, c'est un choix dont il est incapable.
On lui a donc dit comme règle : "si tu te retrouve dans cette situation, tu émet un message pour te plaindre, et tu envoie tout le monde balader.", parce que ca, c'est le genre de règle qu'il est capable de comprendre
Maintenant que les règles que le compilateur doit respecter sont claires, voyons un peu le code que tu as écrit:
Dans le fichier ClassFight.h, nous avons deux définitions de classe:
class FClassA
{
public:
void Adv(int HealthAA, int dgtAA);
int Att(int dgtC, int HealthEC);
int Heal(int HealthC)
private:
int Health;
int dgt;
};
et
class FClassE
{
public:
void Adv(string NameEE, int dgtEE);
int Att(int dgtC, int HealthEC);
int Heal(int HealthC);
private:
string Name;
int dgt;
};
jusque là, il n'y a pas de problème Par contre, les choses se corsent très sérieusement au niveau du fichier cpp, qui est, rappelons le, le fichier qui doit vraiment être traité par le compilateur.
Car on y remarque, si on fait bien attention l'instruction #include "ClassFIGHT.h" à la ligne 2. Cette instruction signifie littérallement "copie ici (entre la ligne 2 et la ligne 3) tout le contenu du fichier dont le nom est donné" (donc, tout le contenu du fichier ClassFIGHT.h)".
Et c'est ce qui va être fait. Si bien que le compilateur va voir le fichier cpp exactement comme s'il était composé du code
/* il y a tout ce qui a été copié depuis le fichier <iostream>,
* on ne va pas s'en inquiéter pour l'instant
*/
// !!!! TOUT CE QUI SUIT VIENT DU FICHIER ClassFIGHT.h !!!!
class FClassA
{
public:
void Adv(int HealthAA, int dgtAA)
int Att(int dgtC, int HealthEC)
int Heal(int HealthC)
private:
int Health;
int dgt;
};
//plan de l'advairsaire
class FClassE
{
public:
void Adv(string NameEE, int dgtEE)
int Att(int dgtC, int HealthEC)
int Heal(int HealthC)
private:
string Name;
int dgt;
};
// !!! ICI COMMENCE REELLEMENT LE CONTENU DU FICHIER .cpp !!!
using namespace std;
class FClassA
{
public:
void Adv(int HealthAA, int dgtAA)
{
Health = HealthAA;
dgt = dgtAA;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
private:
int Health;
int dgt;
};
//plan de l'advairsaire
class FClassE
{
public:
void Adv(string NameEE, int dgtEE)
{
Name = NameEE;
dgt = dgtEE;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
private:
string Name;
int dgt;
};
Si bien que, tu l'auras remarqué, le compilateur se retrouve bel et bien avec ... deux définitions pour chacune des classes. Et qu'il a donc toutes les raisons de ne pas être content :-$
Asmitta a écrit:
Salut, tu as deux classes qui font la même chose, avec les même attributs et méthodes.
Tu as tout à fait raison sur ce point, mais ce n'est pas le problème principal pour ce qui nous occupe.
Ce que je veux dire, c'est que c'est -- très certainement -- quelque chose qu'il faut corriger, mais dont la correction ne résoudra pas le problème de cette "définition multiple"
Asmitta a écrit:
Un header fclass.h (a la place de classfight.h) pourrait avoir cette structure:
#ifndef FCLASS_H
#define FCLASS_H
class FClass{
};
#endif
oui pour le fait d'avoir une seule classe par fichier d'en-tête et pour que le nom du fichier et celui de la classe soient identiques, cela facilite énormément la vie quand on veut rechercher le fichier dans lequel une classe est définie
Quant à l'utilisation de la séquence
#ifndef UN_IDENTIFIANT
#define UN_IDENTIFIANT
/* du code */
#endif
au lieu de l'utilisation de la directive #pragma once, c'est devenu une simple question de choix et de préférences.
Il y a quelques années d'ici, cette utilisation de la directive #pragma n'était comprise (et correctement appliquée) que par un nombre "assez restreint" de compilateurs, la plupart des compilateur ne la comprenant pas ou n'en tenant pas compte.
La tendance c'est totalement inversée depuis, et la grosse majorité des compilateur comprennent et appliquent parfaitement cet usage de la directive #pragma.
Il n'y a donc plus vraiment de raisons pour privilégier la séquence basée sur #ifndef #define et #endif dans le cas présent
Mais revenons à nos moutons ...
C'est très bien, je comprend le problème, mais comment dois-je m'y prendre pour le résoudre?
Hé bien, tu as de la chance, parce que tout ce que je t'ai expliqué concernant la distinction entre déclaration et définition d'une classe s'applique exactement de la même manière aux fonctions (en générale). Ainsi, un code proche de TYPE foo(/* paramètres éventuels*/); sera considéré par le compilateur comme étant la déclaration d'une fonction (le fait de lui indiquer "qu'il existe une fonction nommée foo, prenant tels paramètres et renvoyant une donnée de type TYPE) alors qu'un code proche de
TYPE foo(/* paramètres éventuels*/ ){
/* du code
}
sera considéré par le compilateur comme étant une définition de la fonction.
Le "but du jeu", maintenant, c'est de faire en sorte d'une part que les définitions de classe fournissent les déclarations des fonctions qui la composent au niveau du fichier d'en-tête, et d'autre part que le compilateur puisse trouver la définition des fonctions qui composent les classe au niveau du fichier .cpp afin de générer le code qui sera exécuté par le processeur.
Ton fichier d'en-tête remplit exactement le premier objectif et n'a "pas vraiment besoin" d'être modifié dans l'état actuel des choses (si on décide d'ignorer momentanément la remarque faite par Asmitta).
On ne doit donc modifier que le fichier cpp, et nous pourrions tenter un premier essai sous la forme de
// ca, ca change pas
#include <iostream>
#include "ClassFIGHT.h"
using namespace std;
/* et voici ce qui change */
void Adv(int HealthAA, int dgtAA)
{
Health = HealthAA;
dgt = dgtAA;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
//plan de l'advairsaire
void Adv(string NameEE, int dgtEE)
{
Name = NameEE;
dgt = dgtEE;
}
int Att(int dgtC, int HealthEC)
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int Heal(int HealthC)
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
Et ... ca ne marche pas... Ben non. Heu, ai-je déjà mentionné que le compilateur n'est pas très futé ???
Hé bien, il faut se rendre compte que, pour l'instant, le compilateur n'a absolument aucun moyen de se rendre compte que la première définition de la fonction adv (par exemple) est à mettre en relation avec la fonction exposée par la classe FclassA, et que la deuxième définition qui est donnée de cette fonction est à mettre en relation avec la fonction exposée par la classe FclassE.
Il ne peut donc pas se rendre compte que Healt ou dgt correspond en réalité aux données manipulées par FclassA. Et il ne sait donc pas "d'ou viennent ces données, qu'il ne connait pas". Il a donc toutes les raisons du monde de ne pas être content.
Mais c'est de notre faute, car on n'a pas tenu compte d'une chose particulièrement importante...
En effet, lorsque l'on défini une classe avec un code proche de
/* on simplifie au maximum */
class LaClasse{
public:
void laFonction();
/* tout le reste */
};
on dit explicitement que la fonction appelée laFonction appartient à la classe LaClasse et à elle seule, que la fonction ne peut être utilisée que lorsque l'on dispose d'une instance de la classe LaClasse.
C'est grâce à cela que l'on peut d'ailleurs se permettre d'avoir d'autres (classes qui n'ont rien à voir les unes avec les autres) qui exposent des fonctions portant le même nom, et produisant (ou non) un résultat différent les unes des autres.
Notre obligation est donc de faire comprendre au compilateur que la "version" de la fonction qu'il est occupé à traiter appartient bel et bien à une classe particuliière. Et pour ce faire, nous allons utiliser ce que l'on appelle les "noms pleinement qualifiés": si "quelque chose" (une fonction, dans le cas présent) appartient à une classe bien particulière, on fait précéder le nom de "la chose en question" du nom ... de la classe à laquelle "cette chose" appartient, et on sépare le tout par deux double points ::
Notre fichier .cpp prendra donc la forme finale de
// ca, ca change pas
#include <iostream>
#include "ClassFIGHT.h"
using namespace std;
/* et voici ce qui change */
void FclassA::Adv(int HealthAA, int dgtAA) // voici la fonction Adv qui appartient à la classe FclassA
{
Health = HealthAA;
dgt = dgtAA;
}
int FclassA::Att(int dgtC, int HealthEC)// voici la fonction Att qui appartient à la classe FclassA
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int FclassA::Heal(int HealthC)// voici la fonction Heal qui appartient à la classe FclassA
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
//plan de l'advairsaire
void FclassE::Adv(string NameEE, int dgtEE)// et voici la fonction Adv qui appartient à la classe FclassE
{
Name = NameEE;
dgt = dgtEE;
}
int FclassE::Att(int dgtC, int HealthEC)// et voici la fonction Att qui appartient à la classe FclassE
{
HealthEC -= dgtC;
cout << "Vous avez infliger : " << dgtC << " DEGAT" << endl;
return HealthEC;
}
int FclassE::Heal(int HealthC)// et voici la fonction Heal qui appartient à la classe FclassE
{
HealthC += 15;
cout << "Vous avez recuperez : 15 PV" << endl;
return HealthC;
}
Oufff... nous y somme enfin arrivés... J'espère ne t'avoir pas perdu au fil de mes explications, et que celles-ci te seront utiles
- Edité par koala01 15 avril 2022 à 18:38:41
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
C’est le compilateur C++ n’est pas très futé, il n’y a aucune loi physique ou autre qui empeche d’avoir mieux même avec une machine qui ne lit que des 0 et des 1, la preuve dans d’autres langages on n’a pas à se poser ce genre de questions. N’amalgamez pas l’informatique en général avec le C++
De manière générale, le développement devrait suivre une "certaine logique":
l'expression du besoin: on a "une idée géniale" qui tourne autour de "ce serait syma s'il y avait quelque chose qui ... <ajoutez ce que vous voulez ici>"
L'analyse "fonctionnelle" : que veut on que "la chose" que l'on s'apprête à développer fasse pour nous? Quels sont les services que l'on attend de sa part? Il s'agit essentiellement de s'assurer que l'on a une compréhension suffisante des besoins tels qu'ils ont été exprimés.
L'analyse "technique": De quoi a-t-on besoin pour que "la chose" que l'on veut développer puisse rendre les services que l'on attend de sa part? Comment va-t-on arriver à "faire tenir" les "différents morceaux" ensemble ?
L'algorithmie : Maintenant que l'on sait le "quoi" en ce qui concerne "la chose" à développer, il faut trouver le "comment": comment va-t-elle passer d'une situation particulière à la situation suivante, qui lui permettra d'atteindre l'objectif final
L'implémentation: on sait le quoi, on sait le comment, on sait "où cela doit nous mener", "YAPUKA" écrire le code
Et bien sur, ce n'est absolument pas parce que l'on est passé d'une étape à l'autre, que l'on ne peut pas revenir sur un des étapes qui est pourtant considérée comme "achevée":
Si l'on se rend compte à n'importe quel moment que "quelque chose n'est pas clair", on peut "remonter" depuis n'importe où vers une étapes considérée comme "achevée" pour clarifier les choses
Au pire, cela peut nous faire remonter jusqu'à l'expression du besoin si nécessaire
(désolé pour l'ASCII chart, j'ai essayé de le rendre "aussi clair que possible : les < et les > indiquent le sens dans lequel "vont les choses")
Cette manière de fonctionner nous offre "une chance" de fournir au final un programme qui puisse correspondre au besoins exprimé par celui qui l'a demandé, et, bien sur, cela lui donne aussi l'occasion de dire que "ben, en fait, j'ai réfléchi, et je voudrais aussi que <ajoutez ce que vous voulez ici>" ;).
Et l'énorme avantage de travailler de cette manière, c'est qu'elle s'adapte à toutes les situations: elle permet de gérer de très gros projets particulièrement complexes, tout comme elle permet d'obtenir le code d'une simple fonction dont on se serait dit "tient, j'ai besoin d'une fonction qui fait <telle ou telle chose>"
Au final, l'implémentation proprement dite pourrait être associée à "un long et fastidieux travail de traduction et de dactylographie", car tous les problèmes "les plus intéressants" auront été résolus durant les étapes précédentes.
Ou, du moins devrait on dire que "tous les problèmes intéressants devraient avoir été avoir été résolus durant les étapes précédentes", car c'est souvent le cas, et c'est ce qui fait que certaines personnes persistent à adorer s'occuper de l'implémentation au fil des années
EDIT:
JadeSalina a écrit:
C’est le compilateur C++ n’est pas très futé, il n’y a aucune loi physique ou autre qui empeche d’avoir mieux même avec une machine qui ne lit que des 0 et des 1, la preuve dans d’autres langages on n’a pas à se poser ce genre de questions. N’amalgamez pas l’informatique en général avec le C++
S'il te plait, ne viens pas polluer une discussion la faisant passer ce que tu crois savoir pour une vérité absolue, car tu es encore une fois à coté de la plaque!
- Edité par koala01 15 avril 2022 à 18:34:27
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
> Ce que vous dites par rapport aux déclarations/définitions s’applique en C++ mais ce n’est pas une obligation dans l’absolu, on peut très bien faire différemment, comme en Javascript par exemple
Ce forum est dédié a quel langage s'il te plait?
JadeSalina a écrit:
Et si je pollue les discussions bah dites à abcd de supprimer tous mes messages
@JadeSalina, Pourrais tu -- s'il te plait -- prendre l'habitude, lorsque tu veux simplement "chicanner" sur ce que les autres intervenants ont pu écrire sans apporter quoi que ce soit à la discussion, d'entamer ta propre discussion afin d'aborder le sujet qui te chagrine, afin de ne pas polluer la discussion en cours?
Peut être est-ce déjà trop tard pour celle-ci, mais ca facilitera énormément la vie de tout le monde.
Tu ne dois même pas t'en faire : tu auras forcément les réponses que tu mérites
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Comme c'était à la demande même de JadeSalina, son intervention a été signalée, il faut juste attendre qu'un modo recoive la notification, le reste suivra "rapidement"
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
okay merci pour tes precieux conseils @JadeSalina, tachons juste de résoudre le problème de @ArthurDuflos962 dans la suite S'il te plait. 🧎🏽♂️🧎🏽♂️🧎🏽♂️🧎🏽♂️🧎🏽♂️🧎🏽♂️
@JadeSalina, on est tellement cons que les membres du board de la normaisation n'ont jamais discuté de trucs comme les modules en C++ pour passer outre cet "archaïsme" de la déclaration à la C (venant du temps immémoriel du début des années 70).
Grand Merci à toi, au grand @JadeSalina, de nous éclabousser de ton génie.
Un vieux con taupiste.
- Edité par bacelar 15 avril 2022 à 19:52:04
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Il faut que tu nous montres ton code et le message d'erreur. Ton message ne nous dit rien sur ce qui te bloque. Moi personnellement j'ai meme pas compris ce que tu voulais dire
juste le code d'erreur ne regle pas tout et j'apprend actuellement :[
C'est sur que ça ne règle pas tout, mais sans code ni message d'erreur, on ne va pas avancer.
Allez, je me lance : Tu n'as pas déclaré la variable variable.
Problême Classe C++ avec le Header
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />
<audio class="audio-for-speech" />