Discussion :

[adiks]

Bonjour à tous,

J'aimerai uiliser une DLL existante dans un code C/C++ et je sais pas comment m'y prendre.

1 - Quelle langage entre C et C++ permet leur utilisation ?

2 - Comment les utiliser (principe plus code) s'il vous plaît, ou à défaut le lien d'un tuto assez explicatif ferai aussi l'affaire.

Merci d'avance pour votre aimable attention !

[Bktero]

Il existe des DLL pour C et pour C++, qui ne sont pas (toujours ?) compatibles.

Quand tu programmes, tu as un fichier d'en-tête .h contenant les prototypes des fonctions de la DLL, comme ce serait le cas avec un module normal. Différence : tu ne possèdes pas le .c associé, juste un fichier compilé .dll. On utilise alors une édition dynamique des liens.
Quand le programme s'exécutera, il ira chercher dans la DLL le code binaire dont il a besoin. Il faut pour cela que le fichier DLL soit visible par le programme (même dossier, ou dans les dossiers systèmes qui vont bien).

Ces 3 entrées de la FAQ sont intéressantes : http://c.developpez.com/faq/index.ph...rechercher=dll

[Obsidian]

Hello,

1 - Quelle langage entre C et C++ permet leur utilisation ?

2 - Comment les utiliser (principe plus code) s'il vous plaît, ou à défaut le lien d'un tuto assez explicatif ferai aussi l'affaire.

Tu peux utiliser pratiquement directement une bibliothèque C dans un programme C++. Il faut simplement veiller à encadrer le #include correspondant avec extern "C" { } ce qui permet d'indiquer au compilateur C++ que ce que ce bloc contient est du C, et qui a pour effet principal de d'éviter de décorer les noms de fonctions. C'est généralement ce dernier point qui pose problème lorsqu'on essaie de faire l'édition des liens.

Après, il est possible que la bibliothèque C soit elle-même dépendante d'autres bibliothèques de plus bas niveau qui, au bout d'un moment, peuvent rentrer en conflit avec les ressources du C++. Mais c'est très rare et la plupart du temps, les bibliothèques C++ sont conçues, autant que faire se peut, pour éviter ces phénomènes.

Utiliser des bibliothèques C++ dans un programme C, en revanche, est plus difficile pour des raisons évidentes. Dans ce cas, si seules certaines ressources particulières de cette bibliothèques t'intéressent, tu peux écrire un petit wrapper en C++ en déclarant les prototypes de tes fonctions dans un « extern "C" » mais en compilant quand même avec un compilateur C++. Tu obtiendras une bibliothèque intermédiaire que tu pourras facilement lier avec ton programme et qui manipulera les objets C++ pour toi.

[srvremi]

Tu peux utiliser pratiquement directement une bibliothèque C dans un programme C++. [...] Après, il est possible que la bibliothèque C soit elle-même dépendante d'autres bibliothèques de plus bas niveau qui, au bout d'un moment, peuvent rentrer en conflit avec les ressources du C++. Mais c'est très rare et la plupart du temps, les bibliothèques C++ sont conçues, autant que faire se peut, pour éviter ces phénomènes.

Le cas le plus fréquent que je rencontre est le cas de la programmation réseau. Souvent, un programme C++ utilise les fonctions systèmes C pour utiliser le réseau. Tout le programme est en C++, sauf ces morceaux précis et cela ne pose aucun problème.

Il m'arrive aussi de trouver ce cas de figure en programmation MPI, même si la bibliothèque est codée aussi en C++, les amoureux du Fortran aiment plutôt manipuler les fonctions C.

Bref, tout ça pour dire que normalement il n'y a aucun souci.

@+
Rémi

[Obsidian]

Le cas le plus fréquent que je rencontre est le cas de la programmation réseau. Souvent, un programme C++ utilise les fonctions systèmes C pour utiliser le réseau. Tout le programme est en C++, sauf ces morceaux précis et cela ne pose aucun problème.

Les appels système sont des cas particuliers, toutefois : au bout du compte, ce sont vers eux que seront résolues toutes les fonctions des bibliothèques, quelque soit le langage utilisé, d'ailleurs. En outre, les appels systèmes sont souvent dotés d'une ABI propre et différente de celle que l'on utilise dans les bibliothèques (par exemple, INT 80h sous Linux), ne serait-ce que pour franchir la barrière du mode noyau. Et ce, même s'ils sont au préalable bufferisés par une bibliothèque standard comme cela se passe avec la GlibC.

D'autre part, pour la programmation réseau en particulier, on utilise énormément les sockets, pourtant hors d'âge. Il y a bien des wrappers C++ mais ils ne justifie pas de réécrire la totalité des couches sous-jacentes depuis zéro, surtout que celles-ci se trouvent majoritairement dans le noyau.

Ce qui nous amène au dernier point : les noyaux de la plupart des systèmes d'exploitation sont écrits en C. À commencer par UNIX dont le lien avec le langage C est très fort (ce sont les mêmes auteurs) et qui a engendré un grand nombre de dérivés. Et pour les autres, plusieurs tentatives de réécritures de noyaux en C++ par exemple ont été menées mais la plupart du temps sans résultat satisfaisant : trop gros et trop lourd la plupart du temps.

D'une certaine manière, même aujourd'hui, il se passe la même chose entre le C et l'assembleur mais beaucoup plus tôt : les bootstraps, très limités en espace, les opérations d'initialisation spécifiques aux différents micro-processeurs (par exemple le passage en mode protégé) et autres subtilités sont écrites en assembleur jusqu'à un niveau suffisamment satisfaisant pour embrayer vers le C. Même si le C++ (au contraire de langages comme Java par exemple) est fait pour se passer au maximum de tout framework sous jacent, il ne devient réellement efficace qu'à partir du moment où les fondamentaux d'un système d'exploitation sont en place.