Bonjour,
voilà, il y a une question que je me pose depuis longtemps: les headers de la librairie standard (stdlib, stdio, string.h etc...), ils fonctionnent comment?! parce qu'il y a bien les .h, mais impossible de trouver les .c! comment ça fonctionne alors? (ça doit être pratique pour créer sa propre librairie... meuh non je rigole! )
Merci d'avance
Tout dépend de l'implémentation (de l'environnement tout entier, compilateur, système, etc.). Ca pourrait très bien être magique, le compilateur connaissant tout et se suffisant à lui-même, ou alors il pourrait faire appel à des libc externes, dynamiques, statiques, diverses, 'fin bref, il n'y a rien d'obligatoire.
voilà, il y a une question que je me pose depuis longtemps: les headers de la librairie standard (stdlib, stdio, string.h etc...), ils fonctionnent comment?! parce qu'il y a bien les .h, mais impossible de trouver les .c!
C'est tout l'intérêt d'une bibliothèque. Le code est précompilé et archivé dans un .lib ou un .a (ou l'équivallent en 'partagé' : .dll ou .so).
Comme tu l'as lu sur le cours de M@téo, les .h ne sont que des interfaces.
On a pas besoin des .c, sauf si on voulait modifier ou augmenter la bibliothèque.
Dans un gros développement, on fait des dizaines de bibliothèques dont on assemble les morceaux pour constituer une application. Ca permet de répartir le travail, de tester individuellement chaque bout sans avoir à tout recompiler à chaque fois etc.
Tu connais les fichiers .o ? Ce sont des fichiers dont le code est compilé, mais il manque les adresses des fonctions, il y a comme des "trous" dans le code où est écrit en clair le nom d'une fonction, et au linkage il faudra le remplacer par son adresse, pour y sauter directement.
Dans le dossier /lib tu trouves des .a qui sont des ensembles de .o, ça correspond donc à plusieurs fichiers .c des fonctons standards, qui ont été compilés en .o et rassemblés dans un .a. Quand tu compiles, le compilateur sort d'abord un .o de ton fichier .c, puis le linker recherche les fonctions dans ton .o et les .a des libs, pour sortir le fichier exécutable final.
Donc en fait, tu ne trouves pas de .c mais un format "à moitié" compilé : il continet les fonctions compilées mais il faut encore lier pour les appeller correctement dans un fichier exécutable
edit : je précise tout ça se passe avec GCC sous Windows ou Linux, comme l'a dit rz0 ça pourrait très bien être complètement différent
M@téo en parle dans le chapitre sur la programmation modulaire.
Sinon je vais dire une connerie mais, en désactivant le linker, on obtiendrait donc des .o non ? On pourrait donc créer son propre fichier d'en-tête...
mais, en désactivant le linker, on obtiendrait donc des .o non ?</taille>
Oui.
Citation : mleg
On pourrait donc créer son propre fichier d'en-tête...
Mais, on le peut déjà, tu sais comment créer un fichier d'en tête en fait il "suffit" de créer au moins un .c contenant des fonctions (sans main), le compiler (sans linker, sinon ça plante puisqu'il n'y a pas de main ), garder le .o. Eventuellement on rassemble les .o dans une librairie. Ensuite, on inclut le header, on programme le main et on appelle les fonctions du .h, on compile et on linke avec les .o ou .a déja faits. Ayé, un .exe
Merci à vous, j'ai compris! (ha ba oui c'est expliqué mais bon ça faisait longtemps... enfin bon c'est pas expliqué explicitement comme ça...)
Edit: hé mais.... alors... comme je ne rajoute pas des options de linkages, yen a qui se font automatiquement?
Les .a sont des bibliothèques statiques
Les .dll sont des bibliothèques dynamiques
Concrètement ça veut dire que si tu utilises des .a ils seront inclus dans ton exécutable, tandis que si tu utilises des .dll non.
Avantage des .a : pas besoin de fournir autre chose que l'exe (mais exe plus gros)
Avantage des .dll : exe plus petit (et plus facilement modulable en plugins) mais il faut fournir la DLL en plus de l'exe.
Ok merci
Sinon on les fait comment les DLLs avec gcc? j'ai beau chercher je ne trouve pas. On part des .o? des .c?
Une DLL doit être écrite selon des critères définis par Microsoft. C'est une spécificité de Windows. Il y a un squelette type à réspecter, un fichier de ressources pour définir les fonctions exportées etc. C'est assez complexe. Ensuite, il faut utiliser l'éditeur de liens d'une certaine façon...
Génération : Mingw (Code::Blocks, par exemple) sait produire des DLL...
Dev-Cpp sait aussi produire des Dll .Il suffit de cocher generer une Dll dans le choix du type de projet.(Il sait aussi genere des librairies statique en .a) pour ce que cela interesse.
Heu.. j'ai cherché sur développez.com, mais je ne trouve rien...
Je t'ai renvoyé à un forum. A toi de poser une question là bas...
Citation : Ze moi
Et sur msdn ils ne parlent que VC++
Non. Toute la technologie de développement de Windows y est documentée. Ca va beaucoup plus loin que VC++. Il y a des articles sur les DLL. Il faut fouiller, rechercher...
Pour les DLL il faut une structure spéciale et pour les appeler dans un prog il faut utiliser des fonctions de windows.h(je crois qu'il faut charger un handle et que ça utilise les pointeurs sur fonction)
Merci beaucoup pour le lien! Je dois avouer que je n'ai pas bien cherché (mais je manquait de temps aussi...) Ils disent: "l'adressse de la fonction". je suppose qu'il faut utiliser les pointeurs de fonctions alors?
Edit: non désolé j'avais pas bien compris. Mais après je donne quoi comme options pour gcc?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
If you'd like to join us, read "How do we work at OpenClassrooms"! :)