[SDK] Visual C++
Bonjour
Je cherche les librairies pour developper des applications en openGL pour visual C++ 2005, j'es cherche sur internet et j'es trouver des fichiers a copier dans les repertoires du compilateur mais j'obtien toujour des erreurs a la compilation. "fatal error C1083: Impossible d'ouvrir le fichier include : 'GL/gl.h' : No such file or directory" de quel répertoire il sagit ? du compilateur ou du projet ?
Je cherche aussi les librairie c++ car le compilateur ne trouve pas les fichier en-tet iostrem pourtant il sont bien dans les répertoires eux aussi
Qu'utilisez vous comme sdk ou comme librairie pour visual c++ ?
Merci !
Je cherche les librairies pour developper des applications en openGL pour visual C++ 2005, j'es cherche sur internet et j'es trouver des fichiers a copier dans les repertoires du compilateur mais j'obtien toujour des erreurs a la compilation. "fatal error C1083: Impossible d'ouvrir le fichier include : 'GL/gl.h' : No such file or directory" de quel répertoire il sagit ? du compilateur ou du projet ?
Je cherche aussi les librairie c++ car le compilateur ne trouve pas les fichier en-tet iostrem pourtant il sont bien dans les répertoires eux aussi
Qu'utilisez vous comme sdk ou comme librairie pour visual c++ ?
Merci !
A voir également:
- [SDK] Visual C++
- Visual c++ 2019 - Guide
- Visual petanque - Télécharger - Sport
- Directx sdk - Télécharger - Édition & Programmation
- Visual paradigm - Télécharger - Gestion de données
- Visual watermark - Télécharger - Photo & Graphisme
1 réponse
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
