Discussion :

[devroot]

Bonjour,

J'utilise la dernière version de Code Blocks pour créer une
DLL. Or, les options de création sont "DLL sample" et "C source ".
Le premier fichier source créé est "main.c".

Mais alors comment je fais pour programmer quelque chose en C++
dans cette DLL ?

Merci.

[Médinoc]

Tu ajoutes des fichiers source C++ dedans ?

PS: Une DLL qui exporte des classes C++ faites avec MinGW ne marchera qu'avec des programmes compilés avec MinGW : Seule l'interface C (fonctions C ou fonctions C++ extern "C") est standardisée sous Windows...

[devroot]

Hein ?

Alors ça veut dire que si je veux créer une DLL qui contient un objet afin de
faire tourner cette librairie avec ... disons un programme écrit en Borland C++
Builder... C'est impossible ????

[Médinoc]

Tu ne pourras pas utiliser la classe C++ avec BCB, sauf en utilisant des wrappers C ou un système d'interfaces façon COM/OLE...

[TobyKaos]

Je viens de lire ce topic et cela ne m'enchante pas. Sous cobe blocks avec mingw rien de plus simple pour créer une dll.
De plus j'utilise code::blocks avec gcc sous linux et la aussi super simple de créer un .so (lib dynamique).
Mais avec msvc2005, pff quel galère. Dois-je obligatoirement spécifier des __ddl_export et import afin d'avoir des points d'entrée?

De plus msvc2005 va t il me décorer mes fonctions? Car j'inclus des librairie statics (.lib), cela causera t il des soucie lors de l'exécution d'un programme utilisant ma librairie?

Merci

[Médinoc]

1. J'aimerais bien savoir à quel point il est "rien de plus simple" de créer une DLL sous MinGW. Je rappelle qu'on est supposé choisir quelles fonctions on exporte ou non...
2. Sous MSVC, deux façons d'exporter des fonctions dans un projet DLL:
   
   • Déclarer certaines fonctions (ou classes) en __declspec(dllexport) pour dire "ces fonctions seront exportées". Les fonctions C seront alors exportées avec la décoration "C" standard de Windows (voir Format of a C Decorated Name)
   • Ou écrire un fichier .def qui indique quelles fonctions seront exportées, et permet également de ne PAS mettre certaines fonctions dans la bibliothèque statique d'importation (pour certaines fonctions dont le nom ne change jamais) ou de choisir complètement sous quel nom la fonction sera exportée (une fonction appelée "foo" peut être exportée sous le nom "bar" si on veut).
3. Pour le coup de dllexport, on utilise généralement un fichier d'en-tête et quelque macros pour pouvoir réutiliser le fichier en question. Visual est capable de générer automatiquement un tel fichier d'en-tête, produisant un truc dans ce style: http://www.developpez.net/forums/sho...42&postcount=6
   
   • Ainsi, pour faire une fonction exportée int foo(const char *), il suffit de la déclarer ainsi:
     EXTERN_C MADLL_API int foo(const char *);
     Ce qui donne une fonction exportée par la DLL, et utilisable aussi bien en C qu'en C++.
   • D'ailleurs, toutes les fonctions sont déclarées ainsi sous Windows (sauf qu'en plus, elles ont la convention d'appel WINAPI (__stdcall) au lieu de __cdecl).

Note: Pour des fonctions C ou des fonctions C++ extern "C", il n'y a aucun problème de compatibilité.

Pour des classes C++, le format de décoration dépend du compilateur. Donc, si l'on veut utiliser les classes directement, l'on se retrouve obligé de lier au .lib et de garder le même compilo.
Par contre, on peut utiliser les classes indirectement, avec des "wrappers C" ou un système d'interfaces comme celui de COM/OLE (ou tout système perso).