C++/CLI Wrapping et héritage

Version imprimable

08/06/2009, 15h11
Predicator

C++/CLI Wrapping et héritage
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:

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:

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 ;))
08/06/2009, 16h18
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.

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

Code:

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
}

09/06/2009, 09h27
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 :)
09/06/2009, 09h32
3DArchi

Citation:

Envoyé par 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 :)

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.
09/06/2009, 09h35
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...
09/06/2009, 09h38
3DArchi

Citation:

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

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.

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:

1 2 3 4 string UA::getClass() { return "UA"; }
Puis dans A :
Code:

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...

Citation:
Envoyé par 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:

1 2 3 4 string UA::getClass() { return "UA"; }
Puis dans A :
Code:

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.

09/06/2009, 14h17
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...
09/06/2009, 14h28
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.
09/06/2009, 14h39
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...
09/06/2009, 14h41
3DArchi

Si tu penses avoir ta réponse, pense au bouton :resolu:
09/06/2009, 14h45
Predicator

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