problème avec constructeur

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 :

Code:

---

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 :

Code:

---

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 :

Citation:

---

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

---

Pourtant avant j'ai déclaré

Code:

---

a(3,4)

---

par exemple et ça marchait.


Pourquoi ça ne marche pas quand je fais

Code:

---

Q c;

---

D'avance merci

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

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

Code:

---

Q::Q(int, int){}

---

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

J'ai mis le message d'erreur.

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

Dans mon cpp, j'ai fait :

Code:

---

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,

Code:

---

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

---

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

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.

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.

Citation:

---

Envoyé par matlab_

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.

Citation:

---

Code:

---

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

---

---

Comme le dit rOd :

Citation:

---

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

Code:

---

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.

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

Citation:

---

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.

J'utilise un terminal et lignes de commande

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

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à).

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

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

merci

-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.

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

Salut,

Citation:

---

Envoyé par matlab_

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 :aie:

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 8O:calim2::?

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.

Citation:

---

Envoyé par matlab_

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 ;) )

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 ?

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.

Citation:

---

Envoyé par matlab_

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 ?

---

Citation:

---

Envoyé par 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.

---

White, tu as sans doute mal lu.. l'option -o se contente d'indiquer le non du fichier de sortie ;)

En fait, il faut comprendre la chaine de compilation :

La première chose qui est faite par g++ est d'appeler le préprocesseur (cpp dans cette chaine de travail) qui va passer chaque fichier en revue à la recherche des différentes directives préprocesseur.

Tu peux avoir un aperçu du résultat avec la commande

Code:

---

g++ -c fichier.cpp -o fichier.pre -E

---

(comme il n'existe pas d'extension pour les fichiers préprocessés, l'extension pre semble pas si mal :D)

Si tu ouvres ce fichier, attention les yeux, un simple

Code:

---

1 2 3 4 5 6 7

#include <iostream> int main() { std::cout<<"hello world"<<std::endl; return 0;   }

---

se traduit en 15800 lignes de code à cause des inclusions indirectes ;) :P

La deuxième étape est celle de la génération de code assembleur.
tu peux te faire une idée du résultat avec la commande

Code:

---

g++ -c fichier.cpp -o fichier.s -S

---

Je ne sais plus exactement quel est le backend utilisé dans le cas d'un code C++, mais il n'est pas exclu que ce soit le travail de g++ lui-meme ;)

Vient ensuite l'appel à as pour générer le code "objet" au départ du code assembleur

Le résultat obtenu n'est plus "lisible par un humain" car le code est composé des instructions que le processeur va lui-même utiliser ;)
C'est ce que tu obtiens avec la commande

Code:

---

g++ -c fichier.cpp -o fichier.o

---

Enfin vient l'étape de l'édition de liens, qui correspond à la commande

Code:

---

g++ fichier1.o fichier2.o fichier3.o -o application.exe

---

G++ fait alors appel à l'éditeur de liens (ld) pour générer l'exécutable final.

Son rôle sera de remplacer les différents symboles correspondant aux appels de fonctions par les adresses auxquelles ces fonctions se trouvent réellement en mémoire ;)

On peut aussi parfaitement envisager de générer directement l'exécutable (donc en utilisant des pipes au lieu de fichier *.o) avec une commande proche de

Code:

---

g++ fichier1.cpp fichier2.cpp fichier3.cpp -o application.exe

---

Evidemment, cette manière de travailler devient assez vite fastidieuse dans le contexte d'un projet important, peut etre subdivisé en un nombre important de sous bibliothèques, composé d'une arborescence complexe ou susceptible d'avoir un certain nombre de définitions de symboles pour modifier le comportement à la compilation.

C'est la raison pour laquelle on préfère généralement utiliser un système qui permet d'automatiser la chaine de compilation ;)

NOTA:
Cela correspond aux étapes "logiques" de compilation, cependant, le fait d'appeler la commande g++ -c fichier.cpp -o fichier.o va en fait utiliser des pipes pour passer les différentes étapes (et je ne suis même pas sur qu'il devra effectivement passer par une étape en code assembleur :P)

Bonjour dans le corrigé de cet exam. joint en pdf,

page 3/4

question 2 :

voici la question :

Code:

---

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

int *i = new int[6]; //Question i A la suite de cette ligne, on peut écrire F if (i != NULL) i = 4; A la suite de cette ligne, on peut écrire V if (i != NULL) i[0] = 4; A la suite de cette ligne, on peut écrire F if (i != NULL) i[6] = 4; A la suite de cette ligne, on peut écrire F if (i != NULL) i[] = {1, 2, 3, 4, 5, 6};

---

je ne saisis pas le "vrai" pour la deuxième proposition.

en effet i est un pointeur sur un entier , n'est-ce pas ?

Donc , d'après ce que je sais, il faut utiliser

Code:

---

*i

---

pour désigner des valeurs alors que i tout seul désignerait des adresses ? ou bien ce serait

Code:

---

& i[0]

---

pour désigner l'adresse de

Code:

---

i[0]

---

?

Dans ce cas, pourquoi peut-on écrire

Code:

---

i[0]=4

---

, alors que à ma connaissance i[0] désignerait plutôt des adresses ?


Merci de vos explications

ps: d'ailleurs, dans ce code, on a un

Code:

---

if (i!= NULL)

---

ce qui montre bien que la valeur de i est une adresse

Encore une fois, la seule date à laquelle a été présenté cet examen tend à le disqualifier si tu veux avoir une chance d'apprendre du C++ un tout petit peu moderne.

En datant de 2000, il a pris du retard sur deux versions de la norme et sur un technical report ce qui est, vraiment, très important.

Quand on sait qu'en plus les profs sont très lents à se mettre à jour... :aie:

Ceci dit:

Citation:

---

je ne saisis pas le "vrai" pour la deuxième proposition.

en effet i est un pointeur sur un entier , n'est-ce pas ?

Donc , d'après ce que je sais, il faut utiliser

Code:

---

*i

---

pour désigner des valeurs alors que i tout seul désignerait des adresses ? ou bien ce serait

Code:

---

1 2

& i[0]

---

pour désigner l'adresse de

Code:

---

i[0]

---

---

Oui, mais non...

C'est, quelque part, tout le problème des pointeurs...

Le fait est que i n'est jamais qu'un pointeur. C'est à dire une variable qui contient l'adresse mémoire à laquelle on va trouver un élément du type indiqué.

Mais l'adresse contenue par i est l'adresse qui résulte de new int[6]. Or, new int[6] a eu comme effet de réserver l'espace mémoire suffisant pour pouvoir représenter 6 éléments de type int consécutifs et le résultat est l'adresse du premier élément (celui à l'index 0).

Tu peux donc tout à fait sans problème travailler "comme bon te semble":

Code:

---

*i = 4;

---

fonctionnera en assignant la valeur 4 à "ce qui est pointé par i" et qui correspond à l'élément d'index 0, mais cela aura exactement le même résultat que

Code:

---

i[0] = 4;

---

car l'opérateur [] a pour résultat de dire "prend ce qui se trouve à l'adresse de i et décales toi du nombre d'éléments indiqué entre les crochets" ce qui correspond bel et bien à la même chose ;)

Ce qui est vrai, c'est que tu peux effectivement envisager de passer un array lorsqu'un pointeur est attendu sous la forme de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

/* soient void foo(int * tab) et void bar(int tab[4]) */ int main() { int i[4]; foo(i); // ok : i est bel et bien un pointeur sur le premier élément bar(i); // ok : i est bel et bien un array de 4 entiers }

---

Par contre, tu ne peux pas envisager de passer un pointeur quand un array est attendu

Code:

---

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

/* soient void foo(int * tab) et void bar(int tab[4]) */ int main() { int * i = new int[4]; foo(i); // ok : i est bel et bien un pointeur sur le premier élément bar(i); // nok : i n'est pas un array mais un pointeur }

---

Citation:

---

ps: d'ailleurs, dans ce code, on a un

Code:

---

1 2	if (i!= NULL)

---

---

En effet, et alors... :question:

A ton avis, il s'agit de l'adresse de quoi, selon toi :question:

Si on a mis ce test, c'est uniquement pour s'assurer de la validité du pointeur, et rien d'autre (bien que le test soit, a priori inutile dans ce cas particulier car il y aurait une exception std::bad_alloc() lancée si l'allocation dynamique avait échoué ;))

Bonjour koala et bonjour à tous,

je ne connais pas les fonctions bar et foo dans qui apparaissent dans le dernier post de koala.

Pouvez-vous me dire précisément à quoi elles servent ?

(d'après ce post, elles vient de std)

Merci

Citation:

---

Envoyé par matlab_

Bonjour koala et bonjour à tous,

je ne connais pas les fonctions bar et foo dans qui apparaissent dans le dernier post de koala.

Pouvez-vous me dire précisément à quoi elles servent ?

(d'après ce post, elles vient de std)

---

Pas vraiment...

Ce sont des noms de fonctions que l'on utilise régulièrement pour signifier "toute fonction qui présenterait une signature similaire" :D

c'est comme si on les avait nommées "faitQuelqueChose" et "faitAutrechose" ;)

Bonsoir,

je n'ai toujours pas compris ce que signifient bar et foo.

merci de vos explications

cordialement

Citation:

---

Envoyé par matlab_

Bonsoir,

je n'ai toujours pas compris ce que signifient bar et foo.

cordialement

---

Je ne sais pas vraiment comment t'expliquer les choses autrement:

Cela signifie "si tu as n'importe quelle fonction qui qui présente la signature de foo (comprends: si tu as une fonction qui ne renvoie rien et qui prend un int * en argument), tu peux envisager de l'utiliser à la place de foo (dont le nom est mis de manière "générique")", et "si tu as n'importe quelle fonction qui présente la signature de bar (comprend: si tu as une fonction qui ne renvoie rien et qui prend un int[4] comme argument), tu peux envisager de l'utiliser à la place de bar.

Ce sont des noms de fonctions qui ne correspondent à rien de particulier, mais qui sont mis là parce qu'il faut bien nommer les fonctions.

On utilise ces noms un peu comme on aurait utilisé des noms come "uneFonctionGenerique" ou comme "doSomething"

C'est compris maintenant,

merci