problème avec constructeur [Résolu]

[humanite]

Bonjour,

j'ai fait un constructeur dans une classe pour les nombres rationnels.

Dans le fichier .cpp qui détaille le fichier .h pour les fonctions membres.
Dans le fichier .h, je détaille, j'ai pour le constructeur dans la partie

public :

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

Q(int a=0,int b=1); // le constructeur de la classe Q (le nombre 1 par défaut)

ce qui par défaut , ce qui donne 0/1 par défaut.

Le problème est que , par la suite dans mon int main(), je déclare un certain c comme étant de type Q (rationnel) avec :

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

Q c;

(ça devrait donc appeler la constructeur par défaut)

mais à ce stade, je ne connais pas la valeur de c.

et cela ne fonctionne pas. Voici le message d'erreur :

undefined reference to `Q::Q(int, int)'

Pourtant avant j'ai déclaré

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

 a(3,4)

par exemple et ça marchait.


Pourquoi ça ne marche pas quand je fais

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

Q c;

D'avance merci

[gbdivers]

Bonjour

Pour rappel, le message suivant "ça ne marche pas" n'est pas un message d'erreur valide et n'aide pas du tout. Peux tu donner l'erreur exacte donné par le compilateur ou le comportement inattendu ?

Merci

[galerien69]

tu n'as probablement pas defini ton constructeur dans ton cpp:

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

Q::Q(int, int){}

PS:
a(3,4) n'est pas une declaration mais un appel de fonction.

[humanite]

J'ai mis le message d'erreur.

En effet, j'ai appelé la fonction avec a(3,4)

Dans mon cpp, j'ai fait :

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

1
2
3
4
Q::Q(int a,int b){ // Le constructeur                                                // le constructeur est une méthode
        num=a;
        den=b;
}

Et dans mon .h,

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

Q(int a=0,int b=1); // le constructeur de la classe Q (le nombre 0 par défaut)

[gbdivers]

On va mettre ça sur le coup de la fatigue et de la grippe

[r0d]

Tout ceci a l'air correct, le problème doit venir d'ailleurs.
As-tu bien inclus le fichier d'en-tête adéquat dans le main?
Sinon, copie le code complet, parce que le problème est ailleurs visiblement.

[humanite]

Je suis en train de me dire que mon problème vient peut-être du fait que la classe porte un nom différent du fichier d'en-tête .h qui la contient.

Je ne sais guère.

[r0d]

Je suis en train de me dire que mon problème vient du faire que la classe porte un nom différent du fichier d'en-tête .h qui la contient.

Il n'y a aucun lien entre le nom du fichier et le nom de la classe.

[Lintel-oo]

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

 undefined reference to `Q::Q(int, int)'

Comme le dit rOd :

As-tu bien inclus le fichier d'en-tête adéquat dans le main?

Tu n'as pas inclus ou pas inclus le bon fichier header à l'endroit où tu déclares

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

Q c;

Sinon ça marcherait
Es-tu sur que tu as respecté la casse si tu as inclus le bon fichier ? Ca arrive parfois de se tromper de cette manière et c'est toujours assez ennuyeux de chercher partout pour une toute petite erreur.

[white_tentacle]

C’est une erreur de l’éditeur de lien

undefined reference to `Q::Q(int, int)'

.

Je pense que tu compiles correctement la classe Q, puis correctement ton main, mais qu’à l’édition de lien, tu ne dis pas que le code de*Q se trouve dans le fichier .o généré et pas dans main.o.

Bref, il faut que tu nous dises ce que utilises pour compiler (IDE ou makefile ou ligne de commande), et la structure de tes fichiers et les commandes appelées pour compiler.

[humanite]

J'utilise un terminal et lignes de commande

g++ cl.h
g++ cl.cpp
g++ fichiermain.cpp

[white_tentacle]

Essaie ceci alors :

g++ cl.cpp fichiermain.cpp -o programme

Ensuite, quand tu vas faire un vrai programme, il te faudra un minimum te documenter sur un système de build (makefile basique, cmake, qmake, automake, etc, pas ça qui manque, il faut juste en choisir un, pour des choses simples un makefile basique fait très bien l’affaire, autant commencer par là).

[humanite]

Dans le main, j'avais mis : #include "cl.h"

A quoi sert-il d'ajouter -o ?
Que cela engendre-t-il ?

merci

[white_tentacle]

-o sert simplement à donner le nom du fichier de sortie (par défaut c’est a.out). -c sert à dire de produire un fichier objet, et pas un fichier exécutable (sinon, le linker va râler sur l’absence de main). Dans un premier temps, ce sont les deux options indispensables à connaître.

Je t’invite à lire :
http://gl.developpez.com/tutoriel/outil/makefile/

pour une introduction aux makefile. N’hésite pas aussi à lire l’aide de gcc.

[humanite]

Et pourquoi ça ne marche pas si j'écris seulement g++ cl.h , g++ cl.pp et g++ monfichier.cpp puis ./a.out pour l' éxécuter ?

merci

[koala01]

Salut,

Et pourquoi ça ne marche pas si j'écris seulement g++ cl.h , g++ cl.pp et g++ monfichier.cpp puis ./a.out pour l' éxécuter ?

merci

Simplement parce que g++ est une application comme une autre, et que tu lances trois fois cette application (dont une fois qui ne sert à rien pour g++ cl.h, mais bon... c'est pas le plus grave):
A chaque fois que tu "relances l'application", elle a "oublié" tout ce qu'elle a pu faire lors de ces exécutions précédentes

Mais c'est normal : imagines un peu le foutoir que cela ferait si elle devait se rappeler de tous les fichiers qu'elle a pu compiler depuis qu'elle est installée, dont des projets entiers

[humanite]

Moi, je pensais que quand je faisais g++ cl.cpp puis enfin g++ monmain.cpp séparément, le résultat de g++ cl.cpp était mémorisé quelque part en attendant l'éxécution de monmain.cpp

Je trouve ça curieux, que comme il vient d'être rappelé, tout est oublié à chaque éxécution de g++.

Mais ça semble cohérent en y pensant bien, car si il y a de gros projets, et que des choses ont été modifiées ici où là, la dépendance des fichiers ça et là, pourrait tout perturber.

D'où l'idée du make probablement qui permet de tout mettre en lien et revérifier la cohérence.

[koala01]

Moi, je pensais que quand je faisais g++ cl.cpp puis enfin g++ monmain.cpp séparément, le résultat de g++ cl.cpp était mémorisé quelque part en attendant l'éxécution de monmain.cpp

Je trouve ça sérieux, que comme il vient d'être rappelé, tout est oublié à chaque éxécution de g++.

Mais ça semble cohérent en y pensant bien, car si il y a de gros projets, et que des choses ont été modifiées ici où là, la dépendance des fichiers ça et là, pourrait tout perturber.

D'où l'idée du make probablement qui permet de tout mettre en lien et revérifier la cohérence.

En fait, l'idée des make et autres systèmes similaires, c'est de créer les fichiers objets (comprends : les fichiers qui contiennent le code binaire exécutable) de tous les fichiers *.cpp, puis de passer le relais à l'éditeur de liens sous la forme d'un grand <editeurDeLien> -c *.o -o tonProgramme.exeIl faut aussi savoir que g++ est en fait un "frontend", c'est à dire un programme qui va, lui-même, appeler d'autres programmes (ld qui est l'éditeur de lien par défaut dans le cas présent )

[humanite]

je voulais dire: je trouve ça curieux, j'ai modifié mon précédent post.

merci

Si je comprends, c'est donc ld qui crée le fichier -o ? et g++ appelle ld ?

[white_tentacle]

C’est bien cela.

L’avantage est que g++ t’ajoutes automatiquement toutes les librairies standard c++ quand il appelle ld, t’évitant de le faire toi-même.