Discussion :

[gwadaboug]

Bonjour à tous,

Je souhaite créer un projet C++, et pouvoir le distribuer en tant que librairie. Le problème est qu'il est plutôt facile de créer des librairies C, mais avec le paradigme objet en C++, cela devient tout de suite une autre histoire.

En cherchant sur internet, je suis tomber sur ce lien qui donne quelques explications. Si j'ai bien compris, le problème pour exporter une classe est que le nommage des fonctions et la construction des classes au niveau mémoire n'est pas standardiser. Ce qui fait que d'un compilateur à l'autre voir même d'une version à l'autre, il peut y avoir des problèmes de compatibilité (ABI).

Le lien propose 3 façons de faire :

• Utiliser des méthodes C et des structures
• Utiliser le même compilateur pour la librairie et le client
• Enfin, créer une methode pour instancier ou détruire l'objet

Mais quand je regarde des projets déjà existant tel que Qt, on peut instancier naturellement des classes, en utilisant un compilateur différent.

Je souhaiterais donc savoir comment pourrais je créer une librairie C++, et pouvoir exporter mes classes, en gardant bien entendu tout le paradigme objet (héritage, polymorphisme, ...).

Je vous remercie pour votre aide !!!

[koala01]

Salut,

En fait, Qt nécessite d'être compilé pour chaque compilateur spécifique, et il est largement préférable d'éviter d'utiliser une des dll compilée avec un compilateur particulier (ou une version particulière de compilateur) si ce n'est pas le compilateur que tu utilises.

Tu pourras d'ailleurs remarquer que, sur la page de téléchargement de Qt, on te propose différentes versions en fonction du compilateur que tu prévois d'utilier

Ceci dit, si cela entre dans la "philosophie" de ce que tu veux faire, l'un des moyens les plus simples pour t'assurer que la dll sera compilée avec le même compilateur que celui de l'utilisateur est encore... de lui fournir simplement les sources et le moyen de les compiler par lui-même

[gwadaboug]

Bonjour koala01,

et merci de ta réponse. Le projet que je souhaite faire à pour but d’être Open Source. Donc pour la recompilation de la librairie, il n'y aura aucun problème. Le projet à également pour vocation d’être multiplateforme. Il sera donc compilé pour chacun des systèmes.

Mais la ou je pense avoir un problème, c'est lorsque la librairie est partagée par plusieurs applications. Il faudra alors s'assurer que les applications qui le partage soient compilées avec le même compilateur. Il devient donc déconseillé d'installer une librairie dans le système, car il faudrait s'assurer que chaque application qui l'utilise soit compiler avec le même compilateur.

Ce que je cherche avant tout, ce sont les bonnes méthodes pour commencer mon développement. Je ne voudrais pas revenir en arrière en milieu de projet parce que la réflexion de départs ne suivait pas ce que j'avais l'intention de faire.

bonjour à tous,

Je pense creer ma librairie en C, avec des appels standards, puis créer un wrapper pour C++.
C'est peut être un peu lourd, mais je pense que sa peut fonctionner. Par exemple la SDL est en C, donc plus de problème de compatibilité entre compilateurs.

Est ce une bêtise ? ou est ce une bonne initiative. Bien entendu, ça me donne bien évidemment plus de travail ...

[Nogane]

Bonjour,
J'aurais plus eu tendance a faire le contraire, comme dans la lib ODE par exemple, faire mon code en C++, et créer un wrapper C. Comme ça je garde la puissance du C++ pour créer ma lib, et la portabilité du C pour mon interface DLL.
Remarquez, une alternative serait d'utiliser SWIG pour wrapper votre interface C++ dans tout plein d'autre langage, indépendamment du compilateur utilisé.

[gwadaboug]

Bonjour Nogane,

Je ne connaissais pas SWIG, mais ça à l'air super puissant.
Mais le problème que j'ai, c'est justement de créer une librairie C++. Je voudrais pouvoir faire une librairie (DLL ou SO) avec des objets (donc des classes), et qu'elles soient utilisable pour les compilateur C++ (en fournissant bien entendu la librairie et le header).

Admettons que la librairie soit compiler avec GCC et le programme avec VC++, d’après ce que j'ai lu, il pourrait y avoir des problèmes de compatibilité. Car le nommage des méthodes et l'ABI diffèrent.

Enfin j’avoue être un peu perdu . Mon but est juste de pouvoir créer des classes et les exporter dans une librairie. Ce qui permettrai a d'autre projet de les utiliser. Je ne veux absolument pas perdre mon paradigme objet si je développe en C++. Sinon je me tournerais vers le C.

[koala01]

Ce qu'il faut comprendre, c'est que si tu fournis ta bibliothèque en open source, et, surtout, que tu code de manière portable, tu n'auras de toutes façons aucun problème...

Du moment que tu fournis déjà le nécessaire pour arriver à le compiler sur un système (auto-tools ou CMake sous linux, CMake ou .vcproj voir projet "code::blocks" sous windows), tu pourrais meme très rapidement trouver des gens qui apporteront "leur pierre à l'édifice" en fournissant d'autres système (basés sur auto-tools, par exemple) et qui seront enchantés de constater que leur travail est intégré au projet (c'est ca aussi, l'open source )

Tout ce à quoi TU as à veiller, c'est de coder de manière portable : si tu as l'occasion de compiler ta dll avec Gcc et VC++, par exemple, quel que soit l'edi ou le système de compilation envisagé, tu pourras déjà savoir qu'elle ne nécessitera pas *trop* d'adaptation pour les autres systèmes

De toutes facons, les développeurs C++ ont suffisamment l'habitude (entre autres grace à boost ou à Qt) de travailler avec des dll "système dépendantes"

Alors, bien sur, le "must" serait, effectivement, de créer un "wrapper" qui permet d'utiliser l'ABI C, qui est bien plus clairement définie, mais cela peut, malgré tout, se trouver très bas dans ta "todo list"

[Nogane]

Ah ben si c'est pour du C++ vers C++... SWIG n'est pas fait pour ça(a ma connaissance).

Non la vraiment, je crois que la seul solution qui n’oblige pas a faire du C, c'est de faire un cmake(ou équivalent), et de fournir les sources pour permettre de compiler avec chaque compilateurs désiré.

Dans le pire des cas(parce que je conseillerais quand même l'approche cmake), on peut faire une interface C a un lib orienté objet. Regarde l'interface de ODE par exemple.

On se retrouve avec des fonctions comme ceci:

Code :

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

1
2
3
4
5
6
dWorldID dWorldCreate();
void dWorldDestroy (dWorldID);
void dWorldSetGravity (dWorldID, dReal x, dReal y, dReal z);
void dWorldGetGravity (dWorldID, dVector3 gravity);
void dWorldSetERP (dWorldID, dReal erp);
dReal dWorldGetERP (dWorldID);

Ou dWorldID n'est certainement qu'un typedef de pointeur. Il est évident que chaque fonctions appel une méthode membre par derrière... ni vu ni connue.