Discussion :

[Predicator]

Bonjour,

Je suis en train d'implémenter une lib C++/CLI qui wrappe une autre lib C++, pour que les données soient accessible depuis C#.

Jusqu'à présent je n'ai pas eu de problème à implémenter, mais j'arrive sur un pan glissant de la manip.

En effet, du côté lib C++, j'ai du polymorphisme.

Code :

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

1
2
3
UA
- UB
- UC

J'ai fais en sorte de retrouver ce polymorphisme en C++/CLI dans les wrappers, pas de problème :

Code :

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

1
2
3
A
- B
- C

Le problème se situe dans le passage du C++ au C++/CLI.
J'ai un algo qui renvoie une liste de UA*, et ceux-ci doivent se retrouver sous forme de liste de A^ dans la lib CLI. Mais UA (et A) sont des classes abstraites. Il faut donc utiliser les classes concrètes pour wrapper.

Problème, comment savoir ? Je pense passer par une factory, qui prend en entrée un UA* et rend en sortie un A^. Mais comment cette factory peut savoir sur l'objet o est de type UB* ou UC* ?

Merci pour toute aide sur ce problème, pour lequel je n'ai rien trouvé sur le net (au sens web, pas .net )

[agamitsudo]

Bonjour,

Je ne suis pas sur que cette idée vaille grand chose mais je me lance :

• UB inclut une constante iu static int égale à 0.

• UA inclut une constante iu static int égale à 1.

Le test de cette constante pourrait permettre de différencier les deux types d'objets d'origine lorqu'ils sont "devenus" des A^ ?

A+,
A.

[3DArchi]

Salut,
Il semblerait qu'on soit dans un cas de down_cast nécessaire.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
convertir(UA *p_ua)
{
   if(dynamic_cast<UB*>(p_ua)){
        // -> B
   }
   else
   if(dynamic_cast<UC*>(p_ua)){
        // -> C
   }
   // erreur
}

[Predicator]

C'était plus ou moins ce que j'ai fait, mais je pensais qu'il y aurait peut être plus élégant que le dynamic_cast.
Si je prends le temps, je pense mettre en place une méthode virtuel dans les UA qui renvoit un identifiant, lequel permet à la factory de prendre le bon wrapper dans une map. C'est moins rigide.

Merci pour vos réponses

[3DArchi]

C'était plus ou moins ce que j'ai fait, mais je pensais qu'il y aurait peut être plus élégant que le dynamic_cast.
Si je prends le temps, je pense mettre en place une méthode virtuel dans les UA qui renvoit un identifiant, lequel permet à la factory de prendre le bon wrapper dans une map. C'est moins rigide.

Merci pour vos réponses

Salut,
Je n'avais pas proposé de mettre une méthode virtuelle dans UA car je pensais que tu ne pouvais y toucher : classe d'une bibliothèque et/ou volonté de rester 100%C++. Auquel cas le wrapper doit faire cette conversion et déterminer le type dynamiquement.

[Predicator]

En fait, l'algo qui génère les données est en C++, mais les données doivent être accessibles depuis C#. Dans mon cas, la lib de données C++ évolue en même temps que la lib des wrappers C++/CLI, donc je suis relativement libre dans ce qu'il est possible de faire...

[3DArchi]

En fait, l'algo qui génère les données est en C++, mais les données doivent être accessibles depuis C#. Dans mon cas, la lib de données C++ évolue en même temps que la lib des wrappers C++/CLI, donc je suis relativement libre dans ce qu'il est possible de faire...

Néanmoins, j'hésiterais à mettre dans UA la méthode virtuelle qui génère le A. Car, ça revient à introduire dans la classe UA une partie du wrapper. C'est pour ça que je me demande si la conception la moins bancale n'est pas d'avoir une fabrique qui fait un downcast sur UA pour obtenir le type dynamique et construire le bon A en conséquence.

[Predicator]

Alors la méthode n'est pas là pour générer le wrapper. C'est vrai que ça ne servira qu'à ça, et que c'est "bancal" de ce point de vue, mais ça n'ajoute pas de dépendance. Exemple :

Code :

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

1
2
3
4
 
string UA::getClass() {
   return "UA";
}

Puis dans A :

Code :

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

1
2
3
4
5
6
7
8
 
...
string class = ua->getClass();
String^ mClass = gcnew String(class.c_str());
// Récupère le nom de la classe wrapper en fonction du nom de la classe à wrapper
String^ wrapperClass = getWrapper(mClass);
System::Activator::CreateInstance(wrapperClass);
...

Attention le code n'est pas valide hein, je l'ai écrit directement ici pour présenter le principe...

[3DArchi]

Alors la méthode n'est pas là pour générer le wrapper. C'est vrai que ça ne servira qu'à ça, et que c'est "bancal" de ce point de vue, mais ça n'ajoute pas de dépendance. Exemple :

Code :

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

1
2
3
4
 
string UA::getClass() {
   return "UA";
}

Puis dans A :

Code :

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

1
2
3
4
5
6
7
8
 
...
string class = ua->getClass();
String^ mClass = gcnew String(class.c_str());
// Récupère le nom de la classe wrapper en fonction du nom de la classe à wrapper
String^ wrapperClass = getWrapper(mClass);
System::Activator::CreateInstance(wrapperClass);
...

Attention le code n'est pas valide hein, je l'ai écrit directement ici pour présenter le principe...

Je comprend l'intention, mais je me demande si je ne préfère pas le downcast. En fait, getClass me fait penser à un downcast déguisé qui en plus vient polluer la classe.

[Predicator]

L'avantage est que potentiellement, tu n'as aucune maintenance de code à faire pour la factory. Elle peut prendre une map externalisée (un bête fichier) pour générer un wrapper dont elle n'a même pas connaissance...

[3DArchi]

Ok, je vois. A ce moment, j'aurais peut être découpé en deux : un premier service qui te retourne une chaîne (en fait un identifiant unique) d'après le type dynamique de l'objet et ta fabrique paramétrée par ton fichier (en fonction de l'identifiant). Ca laisse tes classes C++ indépendantes du wrapping.

[Predicator]

C'est exactement ce que j'ai décris. Il manquait juste le fonctionnement de GetWrapperClass, mais ça me semblait évident.
Enfin, c'est si j'ai le temps ^^
Pour l'instant je me contente du dynamic cast...

[3DArchi]

Si tu penses avoir ta réponse, pense au bouton

[Predicator]

Oh, désolé je connais pas encore bien ^^