[SDK] Visual C++
Fermé
Wanou
Messages postés
3
Date d'inscription
mardi 1 août 2006
Statut
Membre
Dernière intervention
3 août 2006
-
2 août 2006 à 22:57
mamiemando Messages postés 32283 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 17 mars 2023 - 3 août 2006 à 01:02
mamiemando Messages postés 32283 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 17 mars 2023 - 3 août 2006 à 01:02
A voir également:
- [SDK] Visual C++
- Visual click avis ✓ - Forum Consommation et internet
- Visual basic download - Télécharger - Langages
- Microsoft visual c++ c'est quoi - Forum Windows
- Directx sdk - Télécharger - Édition & Programmation
- Visual paradigm - Télécharger - Gestion de données
1 réponse
mamiemando
Messages postés
32283
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
17 mars 2023
7 572
3 août 2006 à 01:02
3 août 2006 à 01:02
Petit rappel sur la compilation en C++:
1ere étape : on compile chaque .c .cpp indépendemment. A ce niveau chaque fichier doit avoir connaissance des fonctions venant des autres fichiers, c'est le rôle des #include (preprocesseur). C'est à cette étape qu'apparaissent les erreurs de déclaration et les problèmes liés aux #include
2e étape : on compile chaque module .cpp (ce qui donne sous linux un .o). C'est à cette étape qu'interviennent les erreurs de compilations proprement dite.
3e étape : on recolle les différents .o pour former l'exécutable. A ce stade on vérifie que pour chaque fonction on a bien trouvé le code qui était associée à chaque fonction déclarée dans les .h .hpp. C'est en particulier à cette étape que peuvent intervenir les erreur de fonctions non définies ou définie plusieurs fois.
En fait pour travailler avec une librairie (que ce soit glut, qt, boost...) il faut donc que deux choses soient spécifiées à la compilation.
1) le chemin du repertoire contenant les includes (les .h et .hpp), car la notion #include <...> cherche des headers dans chaque repertoire spécifiés dans le LD_LIBRAIRY_PATH. Sinon il met le message d'erreur que tu as (1ère étape de la compilation)
2) ensuite tu es bien conscient que le code lui même de la fonction n'est de manière générale pas dans le .h. Un code binaire lui est associé, c'est le .dll (sous windows) ou le .so (sous linux). A la fin de la compilation tu recolles tout les morceaux donc en particulier il faut spécifier ou se trouve le fameux .so ou .dll (3ème étape de la compilation).
Bonne chance
1ere étape : on compile chaque .c .cpp indépendemment. A ce niveau chaque fichier doit avoir connaissance des fonctions venant des autres fichiers, c'est le rôle des #include (preprocesseur). C'est à cette étape qu'apparaissent les erreurs de déclaration et les problèmes liés aux #include
2e étape : on compile chaque module .cpp (ce qui donne sous linux un .o). C'est à cette étape qu'interviennent les erreurs de compilations proprement dite.
3e étape : on recolle les différents .o pour former l'exécutable. A ce stade on vérifie que pour chaque fonction on a bien trouvé le code qui était associée à chaque fonction déclarée dans les .h .hpp. C'est en particulier à cette étape que peuvent intervenir les erreur de fonctions non définies ou définie plusieurs fois.
En fait pour travailler avec une librairie (que ce soit glut, qt, boost...) il faut donc que deux choses soient spécifiées à la compilation.
1) le chemin du repertoire contenant les includes (les .h et .hpp), car la notion #include <...> cherche des headers dans chaque repertoire spécifiés dans le LD_LIBRAIRY_PATH. Sinon il met le message d'erreur que tu as (1ère étape de la compilation)
2) ensuite tu es bien conscient que le code lui même de la fonction n'est de manière générale pas dans le .h. Un code binaire lui est associé, c'est le .dll (sous windows) ou le .so (sous linux). A la fin de la compilation tu recolles tout les morceaux donc en particulier il faut spécifier ou se trouve le fameux .so ou .dll (3ème étape de la compilation).
Bonne chance