gcc et math.h (je sais, ça a déjà été posé mais..)

Bonjour,

Je suis (presque) complètement débutante en programmation et j'ai un problème (logique !)
J'ai déjà parcouru un peu le forum (fait des recherches) mais ça n'a pas résolu mon problème....

Je m'explique :

J'ai écrit un "code" qui utilise la librairie math.h (et aussi iostream et fstream sachant que pour iostream, c'est temporaire... le temps de trouver comment faire autrement)

Le problème :

Lorsque je compile avec gcc, j'ai soit une série interminable d'insultes, soit lorsque je retire le ".h" de math.h l'erreur suivante :

Citation:

---

tmp/ccie1EHJ.o: dans la fonction « main »:
trucmuche.cpp: (.text+0x26): référence indéfinie vers « sin »
collect2: ld a retourné 1 code d'état d'exécution

---

Remarque :
A l'époque où j'ai eu quelques cours de C++, on nous avait dit que lorsqu'on avait une série d'insultes lors de la compilation, c'est qu'il fallait retirer le ".h" de certaines librairies. Et effectivement, à l'époque, ça marchait (mais ce n'était pas math.h qui m'insultait dans ce cas). C'est pour ça que j'ai essayé de compiler sans le ".h" de math.h.

Une solution :

J'ai trouvé sur le forum je crois, une solution très simple qui consiste à écrire la ligne de compilation suivante :

Code:

---

gcc -lm -o truc 030507.cpp

---

En voyant ça, j'ai tout de suite essayé..... mais ça ne change pas grand chose...
Avec le ".h" ---> j'ai la série d'insultes;
Sans le ".h" ---> j'ai la réponse suivante :

Citation:

---

050307.cpp:1:16: erreur: math : Aucun fichier ou répertoire de ce type
050307.cpp: In function ‘int main()’:
050307.cpp:41: erreur: ‘atan’ was not declared in this scope

---

Le truc :

J'ai essayé d'écrire un programme très simple qui ne fait que calculer un sinus. Le seul include de ce programme, c'est le math.h

Lorsque je tape la ligne de compilation avec "-lm", ça marche. Aucune insulte, et il reconnait bien math.h.
De plus, pas plus tard que ce matin, j'ai recompilé un programme assez complexe (pas écrit par moi bien sûr...) à partir de son makefile et je n'ai pas eu de problème avec le math.h

Le programme qui me pose problème reprend certaines fonctions du programme complexe que j'ai compilé ce matin, pour le reste, ce sont essentiellement des gestions de flux.
Le includes présents dans mon code :

Code:

---

1 2 3

#include <math.h> #include <iostream> #include <fstream>

---

Bon, comme moi je suis plutôt débutante... je ne sais pas quoi faire. :oops:

Est-ce que ça peut venir non pas de math.h mais des deux autres librairies (qui ne sont présentes ni dans le code tout pourri qui m'a servi à tester la méthode avec le -lm et ni dans le programme complexe qui n'est pas de moi ?

J'espère que vous saurez m'éclairer ... En attendant, j'espère avoir été assez claire dans ce que je raconte..

Hibiscuit

Un peu long ce post :s je suis pas llé jusqu'a la fin mais essaie donc de compiler avec g++ au lieu de gcc !

Oui, je sais que c'est long.....:oops: :oops:

Je vais essayer avec g++ (et maintenant que tu le dis, c'était g++ que j'utilisais lors de mes cours de C++.... mais j'ai la mémoire courte...)
Je ferai ça demain... mon pc est au boulot.
Je dirai ensuite si ça fonctionne ou non.

Merci !!

Hibiscuit

no soucy, bonne nuit!

Lis l'erreur, comprends l'erreur, et applique la solution.
Il ne faut pas faire des "recettes" à base de j'essaie d'enlever un .h ou que sais-je.

L'éditeur de liens dit qu'il ne trouve pas le symbole sin. Cela signifie tout simplement que la bibliothèque mathématique n'est pas liée. Pour la lier, c'est -lm.
Sache néanmoins qu'en C++, elle est déjà liée par défaut, contrairement à C.

En C++, c'est :
#include <cmath>
donc sans le .h, mais avec un c devant, car c'est une bibliothèque C qui a été adaptée au C++.

Bonjour tout le monde,

J'ai testé avec le compilateur g++..... ça marche quand même nettement mieux ! :D

Merci beaucoup !! C'était donc tout bête (comme souvent quand on est débutant :roll: )

Je réédite le premier message pour que ça soit plus court ! Et je le met en tant que résolu.
Encore Merci ! :D


Hibiscuit
------------------------------------------------------------



Pour répondre à une remarque (que j'ai trouvée quelque peu agressive.. :? bien qu'elle ne devait pas l'être) :
Je sais bien que lorsqu'il y a une erreur il faut la lire mais quand c'est un charabia incompréhensible que peut on y faire ?

Un ptit extrait des insultes que j'avais (il y en avait 4fois plus), (uste pour montrer que je peux difficilement décoder ce truc... en tout cas, en tant que débutante, je ne sais reconnaitre que quelques mots et même si ça donne une piste, la débutante profonde que je suis ne sais pas quoi faire !

Citation:

---

/tmp/ccVEUrc5.o: dans la fonction « __static_initialization_and_destruction_0(int, int)»:
050307.cpp: (.text+0x23): référence indéfinie vers « std::ios_base::Init::Init()»
/tmp/ccVEUrc5.o: dans la fonction « __tcf_0 »:
050307.cpp: (.text+0x6c): réf�rence indéfinie vers « std::ios_base::Init::~Init()»
/tmp/ccVEUrc5.o: dans la fonction « main »:
050307.cpp: (.text+0xad): référence indéfinie vers « std::cout »
050307.cpp: (.text+0xb2): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)»
050307.cpp: (.text+0xba): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)»
050307.cpp: (.text+0xc2): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&))�
050307.cpp: (.text+0xd0): référence indéfinie vers « std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream()»
050307.cpp: (.text+0xee): référence indéfinie vers « std::basic_ifstream<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode)»
050307.cpp: (.text+0x101): référence indéfinie vers « std::basic_ios<char, std::char_traits<char> >::operator void*() const»
050307.cpp: (.text+0x119): référence indéfinie vers « std::cout »
050307.cpp: (.text+0x11e): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)»
050307.cpp: (.text+0x126): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)»
050307.cpp: (.text+0x12e): référence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&))»
050307.cpp: (.text+0x155): référence indéfinie vers « std::basic_ofstream<char, std::char_traits<char> >::basic_ofstream()»
050307.cpp: (.text+0x183): référence indéfinie vers « std::basic_ofstream<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode)»
050307.cpp: (.text+0x196): référence indéfinie vers « std::basic_ios<char, std::char_traits<char> >::operator void*() const»
050307.cpp: (.text+0x1ae): référence indéfinie vers « std::cout »
050307.cpp: (.text+0x1b3): réf�rence indéfinie vers « std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)»

---

rajoute using namespace std; dessous tes includes et enleve tous les std::

sinon compiler du C++ avec un compilateur de C ca passe pas trop !

Citation:

---

Envoyé par lun4t1k

rajoute using namespace std; dessous tes includes et enleve tous les std::

---

Mauvais conseil.

Citation:

---

sinon compiler du C++ avec un compilateur de C ca passe pas trop !

---

gcc est capable de compiler du C++ sans probleme pour autant que les fichiers aient la bonne extension. Si ce n'etait pas le cas, le probleme aurait ete trouve bien plus tot.

pour un débutant et le code qu'il en fait, rajouter using namespace std simplifie la compréhension du code.

Code:

---

pour autant que les fichiers aient la bonne extension

---

Ce n'était pas le cas.

Citation:

---

Envoyé par lun4t1k

pour un débutant et le code qu'il en fait, rajouter using namespace std simplifie la compréhension du code.

---

Apprendre des mauvaises manieres ne simplifie pas l'apprentissage. Si il y a une chose que j'ai apprise lors de mon experience d'enseignement, c'est que de montrer de mauvais exemples pour simplifier complique. En programmation ce qui m'enerve le plus de ce point de vue est l'absence de gestion correcte des erreurs.

Citation:

---

Code:

---

pour autant que les fichiers aient la bonne extension

---

Ce n'était pas le cas.

---

Mais si. Ils etaient bien compiles. C'est l'edition de liens qui foirait (et une des differences entre gcc et g++ c'est les libs par defaut).

Code:

---

Si il y a une chose que j'ai apprise lors de mon experience d'enseignement

---

Arf j'ai compris, rien a faire ils ont toujours raison.

Mon point de vue: Lorsque l'on fait des études d'informatiques (jusqu'au master) on n'apprend pas aux eleves à ne pas utiliser using namespace std;
Pourquoi? pour simplifier

Code:

---

de mauvais exemples pour simplifier complique.

---

Etrangement ca ne m'a jamais compliqué!

donc avide de connaissance, pourquoi ne faut il pas utiliser le namespace? :calim2:

Citation:

---

Envoyé par lun4t1k

Code:

---

Si il y a une chose que j'ai apprise lors de mon experience d'enseignement

---

Arf j'ai compris, rien a faire ils ont toujours raison.

---

Qui "ils"? Il n'y a que moi qui ait toujours raison ! ;)

Citation:

---

Mon point de vue: Lorsque l'on fait des études d'informatiques (jusqu'au master) on n'apprend pas aux eleves à ne pas utiliser using namespace std;
Pourquoi? pour simplifier

---

Et ce n'est pas une bonne chose.

Citation:

---

Code:

---

de mauvais exemples pour simplifier complique.

---

Etrangement ca ne m'a jamais compliqué!

donc avide de connaissance, pourquoi ne faut il pas utiliser le namespace? :calim2:

---

Parce que ça importe un nombre indéterminé de noms communs. Et qu'un changement quelque part va peut-être introduire un conflit à cause de ces noms importés.

C'est particulièrement vrai dans le cas des fichiers include, pour lesquels en plus tu forces tous les utilisateurs à subir cette importation, mais c'est vrai partout.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Parce que ça importe un nombre indéterminé de noms communs. Et qu'un changement quelque part va peut-être introduire un conflit à cause de ces noms importés.

C'est particulièrement vrai dans le cas des fichiers include, pour lesquels en plus tu forces tous les utilisateurs à subir cette importation, mais c'est vrai partout.

---

Qu'entends-tu par un changement quelquepart? Je ne vois toujours pas les problèmes que pourraient causer l'utilisation du namespace std! (désolé :oops: ). pour un fichier d'entete, je suis d'accord.

Ou au pire et je ne pense pas que ce soit de mauvais gout, remplacer le using namespace std par using std::cout ?
Mais il n'empeche que je ne vois les conflits avec d'autres namespaces que pourraient générer une telle utilisation.

Citation:

---

Envoyé par Developpez! ^^

Il est conseillé de limiter l'utilisation de using namespace car cela fait tout simplement perdre l'utilité des namespaces. En particulier, son usage est à proscrire dans les fichiers d'en-tête, ainsi que dans les cas où il génère des conflits avec d'autres namespaces.

---

La FAQ reste assez vague a ce sujet. :/

Autre exemple: je veux créer une fonction à nombre variable (connu) de paramètres sans utiliser stdarg.h.
utiliser pour deux fonctions (la même) deux namespaces est il "propre"?
comme indiqué http://c.developpez.com/faq/cpp/?pag...ACE_definition
Et je pense que par conflit avec d'autres namespace c'est là que l'on veut en venir. Mais on ne va pas donné un nom de namespace deja utilisé?

merci!

Exemple presque vécu. Tu utilises les listes de std avec une clause usign. Quelqu'un modifies un en-tête que tu utilises pour inclure l'en-tête d'un interpréteur lisp qui défini un type list global (normal, l'interpréteur est écrit en C). Résultat ton code ne compile plus à cause du conflit.

Ce sont des choses qui passe assez bien sur des petits projets, sur des plus gros, c'est plus génant. Surtout que dans ce genre de cas, les messages d'erreur ne sont pas particulièrement compréhensibles, en particulier quand on n'a pas idée de ce qui a changé.

quelle idée, tu donnes ton code, il le change ca marche plus, il se démer*e! lol
ok compris merci.

J'ai jamais donné mon code. Je suis responsable d'un module. J'utilises des services fournis par un autre module qui est maintenu au Japon. Ses en-têtes ont évolué de manière raisonnable. Mon code n'a pas changé mais ne compile plus.

le "tu" était général ^^ ( à remplacer par "on") :mrgreen:
merci de tes précisions. bonne continuation.
En fait c'est dans un souci d'évolution du produit...