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