Discussion :

[vikki]

Bonjour à tous,

J'aimerais implémenter un petit système de plugins en C++ (et donc fournir un petit SDK pour le développement des plugins). Ma première question est: est-il possible d'utiliser des bibliothèques dynamiques (contenant du code C++) dans un programme compiler avec un compilateur différents (typiquement, programme principal avec visual c++ et dll avec mingw) ?

Dans le cas où cela est possible, c'est à ma connaissance une mauvaise idée d'utiliser l'opérateur delete sur un objet alloué par opérateur new issu d'un compilateur diffèrent. Par exemple, mon SDK fourni une classe abstraite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class IObject
{
virtual ~IObject()
{}
 
virtual int get_int() = 0;
};

Le pluggin définit une class héritant de IObject et exporte la fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IObject * createObject() {return new MyObject();}

Le programme principal charge la dll et récupère un IObject* via la fonction createObject() définie dans la dll (utilisant donc l'opérateur new de mingw). Il détruit ensuite l'objet avec le delete de visual (je crois). Cela risque-t-il de poser problème?

EDIT: après avoir un peu lu ceci et ceci (referencés dans un précèdent post), cela semble déjà problématique entre différentes versions d'un même compilateur.

[Emmanuel Deloget]

Le standard C++ ne définit pas l'interface entre binaires qui serait nécessaire à une telle interopérabilité. De plus, elle laisse dans le flou certaines considérations importantes, notamment sur le code de la librairie standard, ce qui peut poser des problèmes. Par exemple, si l'implémentation de std::string de mingw est très différente de celle de VC++, quel code vais-je devoir exécuter pour manipuler une chaine de caractère passée en paramètre d'une fonction de la DLL ?

La seule solution interopérable existant à l'heure actuelle, c'est le passage via une interface C. Comme tu le dis, même compilateur mais version différentes peuvent poser des problème (c'est pire que ça : même compilateur, même version, mais options de compilation différentes (par exemple passer de debug en release) peuvent provoquer des erreurs à l'exécution.

[Emmanuel Deloget]

Bonjour à tous,

J'aimerais implémenter un petit système de plugins en C++ (et donc fournir un petit SDK pour le développement des plugins). Ma première question est: est-il possible d'utiliser des bibliothèques dynamiques (contenant du code C++) dans un programme compiler avec un compilateur différents (typiquement, programme principal avec visual c++ et dll avec mingw) ?

Dans le cas où cela est possible, c'est à ma connaissance une mauvaise idée d'utiliser l'opérateur delete sur un objet alloué par opérateur new issu d'un compilateur diffèrent. Par exemple, mon SDK fourni une classe abstraite:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class IObject
{
virtual ~IObject()
{}
 
virtual int get_int() = 0;
};

Le pluggin définit une class héritant de IObject et exporte la fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IObject * createObject() {return new MyObject();}

Le programme principal charge la dll et récupère un IObject* via la fonction createObject() définie dans la dll (utilisant donc l'opérateur new de mingw). Il détruit ensuite l'objet avec le delete de visual (je crois). Cela risque-t-il de poser problème?

EDIT: après avoir un peu lu ceci et ceci (referencés dans un précèdent post), cela semble déjà problématique entre différentes versions d'un même compilateur.

Pour répondre à cette question spécifique : new dans une DLL == delete dans cette même DLL. L'implémentation de l'allocation / désallocation mémoire est une des choses qui varie le plus.

Et pour répondre à l'autre question implicite : les classes virtuelles ne sont pas nécessairement implémentées de la même manière par VC++ et pas g++ ; VC++ utilise une table de fonctions virtuelle située à l'offset 0 de l'objet (objet qui est pointé par ecx). Même si ce n'est pas impossible, il n'est pas dit que g++ fasse la même chose - pire, il n'est pas dit que g++ fera toujours la même chose dans le futur.

[vikki]

Salut et merci pour ta réponse.
Donc cela semble problématique dans tous les cas. Pour le cas du new/delete, je peux peut être me débrouiller en renvoyant un shared_ptr avec deallocateur fournit dans la dll plutôt qu'un pointeur nu. Par contre, cela va poser problème de manipuler mon objet (compiler avec mingw) dans mon programme (visual c++) puisque son implémentation sera différente (vtable, gestion des esceptions je crois, etc...). Je n'ai pas trop d'expérience sur ce sujet, mais comment les grosses applications utilisant un système de plugins gèrent-elles ce type de problèmes?

EDIT: mon plugin contient du code C++ mais n'exporte qu'une fonction (avec extern "C"), les classes à exporter étant enregistrée dans cette fonction via une bibliothèque de réélection (boost.python dans mon cas). Cela pose peut-être moins de problèmes.

[Emmanuel Deloget]

Salut et merci pour ta réponse.
Donc cela semble problématique dans tous les cas. Pour le cas du new/delete, je peux peut être me débrouiller en renvoyant un shared_ptr avec deallocateur fournit dans la dll plutôt qu'un pointeur nu. Par contre, cela va poser problème de manipuler mon objet (compiler avec mingw) dans mon programme (visual c++) puisque son implémentation sera différente (vtable, gestion des esceptions je crois, etc...). Je n'ai pas trop d'expérience sur ce sujet, mais comment les grosses applications utilisant un système de plugins gèrent-elles ce type de problèmes?

Elles ne le gère pas : les plugins sont soit compilés avec le même compilateur (et même settings) où alors le plugin n'exporte que des fonctions C.

EDIT: mon plugin contient du code C++ mais n'exporte qu'une fonction (avec extern "C"), les classes à exporter étant enregistrée dans cette fonction via une bibliothèque de réélection (boost.python dans mon cas). Cela pose peut-être moins de problèmes.

A toi de voir. L'idée est de passer par le plus petit dénominateur commun - la fonction C, avec des types simples (c'est à dire par de type composé).

[Médinoc]

Sinon, sous Windows, il y a le format COM (Component Object Model) : Cela définit comment faire une interface C++ pour qu'elle soit compatible entre les différents langages utilisant COM.

Le problème du delete est résolu en obligeant les objets à se détruire eux-mêmes (quand leur compteur de références intrusif arrive à zéro).

[vikki]

Bon, ca commence à devenir rude, les options diminuent. Mais cela m'ennuierait d'obliger les développeurs de plugin à acheter une licence visual (même si les versions express peuvent dépanner) et je ne souhaite pas passer sous mingw.

Aux vues des restrictions d'utilisation, cette solution devrait passer:
Seule une fonction C est exportée dans la dll. Cette fonction sert à enregistrer dans un système de réflexion (pour l'instant boost.python ou CAMP) des classes non triviales. Je ne pourrais ensuite manipuler ces classes que via les metaclass les représentant, sans jamais chercher à accéder à la véritable structure sous-jacente. Malheuresement, cela m'oblige à exporter tout le contenu de la classe auquel je souhaite accéder (variables et fonctions membres) dans mon système de réflexion.

[Médinoc]

Si tu développes un système compatible COM, n'importe quel compilo C++ pour Windows marche (aussi bien MinGW que Visual), et si y joins la Type Library, je pense qu'on devrait même pouvoir créer des plug-ins en VB6 ou encore d'autres langages.