couple new/delete avec differents compilateurs

Version imprimable

06/01/2011, 22h45
vikki

couple new/delete avec differents compilateurs
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:

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:

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.
07/01/2011, 09h48
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.
07/01/2011, 09h52
Emmanuel Deloget
Citation:
Envoyé par 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:

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:

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.
10/01/2011, 09h09
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.
10/01/2011, 12h23
Emmanuel Deloget

Citation:

Envoyé par 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?

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.

Citation:

Envoyé par vikki

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é).
10/01/2011, 14h59
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).
10/01/2011, 15h02
vikki

Bon, ca commence à devenir rude, les options diminuent. Mais cela m'ennuierait d'obliger les développeurs de plugin à acheter une licence visual :aie: (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.
10/01/2011, 15h05
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.
10/01/2011, 15h20
vikki

Citation:

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.

Le logiciel que je développe actuellement est cross-platform (en tout cas devra l'être dans un futur proche), donc COM ne semble pas possible. Par contre je viens de découvrir, suite à ton post, XPCOM qui semble être l'équivalent multiplateforme, à voir. L'avantage de boost.python etant qu'il permet (simplement), de développer indifféremment des plugins en C++ et Python (j'utilise déjà beaucoup de Python dans le soft).
10/01/2011, 15h43
Luc Hermitte

Tout un chapitre de Imperfect C++ de Matthew Wilson adresse cette problématique de communication entre objets compilés par des compilos différents et résidant dans un même espace mémoire (car il existe toujours les middleware au pire (COM/XPCOM/CORBA/ICE?/...)

Entre autres choses il donne une table (asymétrique!) de compatibilité entre les divers compilos sous Windows. (Aujourd'hui, la table date un peu).
10/01/2011, 17h52
poukill

Intéressant ce Imperfect C++, je note !
CORBA c'est lourd quand même. DDS un peu moins je trouve. Ice je connais pas mais j'en ai entendu du bien.
M'enfin j'osais imaginer qu'on pouvait se passer de ce genre de chose pour faire des plugins !!! Moi qui voulait me lancer dedans pour le boulot ! :cry:
10/01/2011, 23h18
vikki

Pour l'instant je ne pense pas avoir besoin d'un système très lourd (ce que CORBA et XPCOM semblent être), "simplement" donner la possibilité d'implémenter sa petite classe à partir d'une interface. En fait, je risque d'être le seul à utiliser ce système de plugin , les autres utilisateurs me fournissant les specs en s'attendant que ce soit fait le lendemain (même dans ce cas, le développement d'un plugin reste plus agréable que l'ajout barbare dans l'appli principale). Pouvoir étendre le système à l'aide de scripts plus simples à développer pour l'utilisateur lambda (dans mon cas en Python) est également un gros plus. Pour l'instant j'implémente un système simple basé sur boost python et je vais tester ca sur divers compilos/plateforme pour m'assurer des compatibilités (tout en me renseignant sur les autres technos).

On prévoit cependant dans le futur (lointain) de diviser l'appli en processus indépendant (par souci de sécurité principalement) et là, CORBA, XPCOM ou DDS me semblent incontournables.

Le Imperfect C++ semble être recommandé un peu partout sur la toile concernant les systèmes à base de plugins (et pas uniquement), merci bien pour l'info :ccool:
26/01/2011, 00h19
vikki
Bonjour à tous,

Je fais remonter le sujet suite aux quelques problèmes que j'ai pu rencontrés. Pour l'instant, mon système de plugin basé sur boost.python fonctionne correctement, j'arrive à exporter des fonctions et des instances entre mes dll et mon programme principale. Ce que je ne comprend pas bien, c'est le comportement des variable globales entre mon exe et les dll. Je m'explique: l'exe et les dll link statiquement avec la même lib définissant une variable global (boost.python dans mon cas, avec une variable static definie quelque part et semblant contenir une sorte de map de type_info -> fonction). Or, cette variable globale semble bien partagée entre tous les acteurs lorsque l'exe et les dll sont compilées avec les mêmes parametres (je veux dire même compilateur, options de compilation et surtout mode debug/release).

Y a-t-il un ensemble de règle claire permettant de s'assurer le partage de cette variable globale (plutôt que d'avoir une instance différente dans chaque binaire)?

J'ai egalement remarqué que boost.python redefinit sa propre classe type_info se contentant d'encapsuler un pointeur vers un std::type_info, avec comme justification:
Code:

1 2 3 // type ids which represent the same information as std::type_info // (i.e. the top-level reference and cv-qualifiers are stripped), but // which works across shared libraries.
Pourquoi ca fonctionnerait mieux entre lib dynamique :calim2: (à part peut être le fait que la classe ne définie aucune fonction virtuelle)?