Qt dans DLL C++

Prenons un exemple concret bien que simpliste : Supposons que la fonction à transmettre ait le prototype suivant :

Code:

---

1 2 3 4 5 6 7 8 9

struct Point { Point(...); private: int x; int y; };   string doSomething(string const &s1, Point p);

---

Je suis très curieux de voir comment tu enrobes simplement et sans problèmes une telle fonction en C.

Citation:

---

Envoyé par Médinoc

Les exceptions ne sont pas propagées pareil d'un compilateur à l'autre, elles ne sont donc pas censées être autoriser à franchir la barrière d'une DLL portable.

---

En effet. Ce qui signifie qu'il faut d'un côté les attraper toutes, les représenter d'une manière qu'on peut transférer par l'interface d'une DLL portable, puis de l'autre côté relancer une exception de même type. Je ne sais pas écrire ce genre de code avec le C++ actuel, même en admettant le même compilateur avec les mêmes options des deux côtés. Un problème du même genre existe pour transmettre les exceptions entre un thread et le thread qui l'a lancé, et il a demandé des modifications du langage pour y parvenir.

Voir par exemple http://www.open-std.org/jtc1/sc22/wg...006/n2107.html et ses successeurs pour un exposé plus détaillé. Donc, en C++0x, je saurai le faire en admettant un même compilateur avec les mêmes options de chaque côté. Pas dans le cas général.

Code:

---

1 2 3 4 5 6 7 8 9

struct Point { Point(...); private: int x; int y; };   string doSomething(string const &s1, Point p);

---

Dans une API C, il n'y a pas de classe dans les signatures donc pas de string ni de classe public Point.
On utilise des structures C et pas des structs C++.
Il faut aussi correctement configurer dans les .h définissant les structures les options qui rendront leurs définitions non ambigues comme l'alignement, le padding etc... (dans le fichier et non dans la configuration de la chaîne de compilations)

Donc On remplace
- "struct Point" c++ par une "struct Point" C
- string const &s1 pas LPCSTR
- string par quelque chose en accord avec les paradigmes de partages de données de l'API C.

Citation:

---

Envoyé par bacelar

Donc On remplace
- "struct Point" c++ par une "struct Point" C
- string const &s1 pas LPCSTR
- string par quelque chose en accord avec les paradigmes de partages de données de l'API C.

---

Donc si je suis bien ton raisonnement, ta fonction aura comme prototype une truc comme :

Code:

---

CodeDeRetour doSomethingWrapper(char const *s1, PointWrapper p, char **result);

---

Et tu auras du :
Avant de faire quoi que ce soit :
- Définir une structure PointWrapper
Côté appelant :
- Copier les données de Point dans PointWrapper
- Récupéré le c_str de la chaîne passée en entrée
- Appeler la fonction de wrapping
Dans la fonction de wrapping :
- Appeler la fonction C++ wrappée
- Allouer une zone de mémoire pour stocker le résultat
- Gérer les possibilités d'échec de cette allocation
- Copier le résultat dans cette zone
- Tout en t'assurant que si une exception est émise par la fonction wrappée, elle sera attrapée et transformée en code d'erreur de retour de la fonction
Au retour de l'appel de la fonction de wrapping :
- Vérifier le code de retour, retransformer le code de retour en exception (chose impossible de manière générique dans l'absolu, voir mon autre post)
- Créer une chaîne à partir de la zone de mémoire remplie par le résultat
- Effacer cette zone de mémoire

Ton wrapping a quand même causé l'écriture de pas mal de code supplémentaire, pour une fonction très simple, et a demandé une allocation mémoire et une copie de chaîne, ainsi que la création d'un wrapper de point et une copie aussi.

C'est ce que je voulais dire en disant qu'il y a un coût. Dans beaucoup de cas, si je travaille sur un environnement où un compilateur est en quasi-monopole, je préfère pour ma part dire : Vous devrez faire votre code avec tel compilateur, et telles options. C'est finalement moins contraignant.

Et c'est à peu près la même chose sous COM, en supposant une compatibilité élevée ("automation-compatible") :

Code:

---

HRESULT doSomethingWrapper(BSTR s1, IPoint* p, BSTR *result);

---

Sachant que l'objet Point ne peut être manipulé que par référence tant qu'on ne met pas les mains dans le cambouis du marshalling. Par contre, dans le cas présent, il peut sans doute être avantageusement remplacé par un tableau (SAFEARRAY) de deux entiers.

...Mais au moins, en COM, on peut quand même avoir une syntaxe pointeur->méthode. C'est déjà ça.

Edit: Et puis, si on se limite au C++, on n'est pas obligé d'être "automation-compatible". Auquel cas, on peut utiliser une structure Point pratiquement telle quelle, définie dans l'IDL.

Sur aucun environnement, il y a un monopole de compilateur, et les options de compilation différentes peuvent rendre les lib incompatibles. L'utilisation de librairies externes peut interdire l’utilisation de certaines options utilisées par le "fameux" environnement.

La structure de Wrapping fait partie du .h de la librairie.
Un simple opérateur de cast entre la classe Point du module appelant vers la structure de Wrapping fera l'affaire pour le passage transparent de l'instance.
Si la classe est bien faite, il n'y aura même pas de recopie des éléments.

Le traitement coté librairie de l'appel est factorisé par l'utilisation d'une MACRO.

Franchement, ce n’est vraiment pas lourd, à moins d'avoir des centaines de structures non opaque et une gestion mémoire bizarre (normalement, c'est plus simple de faire l'allocation chez l'appelant que chez l'appelé).

Citation:

---

Envoyé par bacelar

Un simple opérateur de cast entre la classe Point du module appelant vers la structure de Wrapping fera l'affaire pour le passage transparent de l'instance.

---

Je vois mal comment un tel cast pourrait marcher...

même layout mémoire entre les membres de la classe et les champs de la structure.

Tu parles donc d'un comportement indéterminé qui a des chances de marcher selon les compilateurs et leurs options. Pour du code se voulant indépendant de ces derniers...

Tout compilateur sérieux a les options de compilations nécessaires pour maitriser complètement le lay-out mémoire d'une structure C.
Si les options sont différentes entres les compilateurs, il suffit de factoriser les divergences dans un fichier d'en-tête et d'utiliser les #ifdef.

Il n'y aura donc aucun souci de portabilité si ce fichier est à jour.