Conversion de Java en C++

bonjour,:lol:

Je suis en train de convertir un driver XTLM écrit en Java pour l'avoir en C++.
Jai des problèmes de plusieurs ordre:
Les bibliothèques HTML sont disponibles seulement en Java.
J'ai du mal a identifier les déclarations de Java
ainsi j'ai réussi à passer la compilation sur

Code:

---

1 2	case XMLStreamReader::START_ELEMENT:

---

mais je ne sais pas déclarer les éléments de cette instruction, ni modifier l'instruction pour la faire passer à la compilation (je ne parle ni d'édition de lien, ni de tests, à ce niveau du travail).

Code:

---

1 2	MCE_Constantes.element_MCPROP.equals(r.getLocalName())

---

Je serais heureux de bénéficier de conseil sur cette migration.
Celui qui me donnera une déclaration et l'instruction modifié sera mon meilleur conseil. Ce sera :ccool:

Citation:

---

Envoyé par JeanNoel53

mais je ne sais pas déclarer les éléments de cette instruction, ni modifier l'instruction pour la faire passer à la compilation (je ne parle ni d'édition de lien, ni de tests, à ce niveau du travail).

Code:

---

1 2	MCE_Constantes.element_MCPROP.equals(r.getLocalName())

---

---

Il s'agit d'une classe appelée MCE_Constantes qui possède un membre statique (et peut être constant) de type String appelé element_MCPROP. Ensuite c'est comparé au résultat de getLocalName() appelé sur r et ça renvoie donc true ou false.

En c++ ça donnerait :

Code:

---

MCE_Constantes::element_MCPROP == r.getLocalName()

---

Ou alors

Code:

---

MCE_Constantes::element_MCPROP == r->getLocalName()

---

Si r est un pointeur.

Bref, on a beaucoup trop peu d'infos. Tu sais faire du java ou du C++ à la base ? D'une manière général, C++ ne fournit pas de type String de base, il faut aller le chercher dans la STL, et les objets ne dérivent pas tous d'un seul et même super objet comme en java. De plus, les équivalents aux listes, aux tableaux et aux String en java ne s'utilisent pas avec les mêmes méthodes en c++. Tu devras donc faire beaucoup de choix et peut être implémenter plus de choses.

D'abord Merci de ta réponse qui contient des éléments probants:D
Ensuite, J'ai une forte expérience du C, une expérience significative du C++ et quelques notions de Java

J'ai choisi pour ce projet de convertir systématiquement le type String de Java en std::wstring
cela donne la déclaration minimale de la classe suivante:

Code:

---

1 2 3 4 5 6 7 8

class MCE_MCProp { public: int status; setAttribute( std::wstring, std::wstring); std::wstring element_MCPROP; };

---

J'ai modifié la ligne en question en suivant ta proposition

Code:

---

1 2	MCE_Constantes::element_MCPROP == r.getLocalName()

---

J'ai vérifié que la déclaration de r.getLocalName renvoi un type std::wstring
Par contre, le compilateur n'est pas encore content :mrgreen:
Il me dit : symbole element_MCPROP non défini
Comment le satisfaire pour que je sois :ccool:

Je suis :ccool: j'ai regardé plus haut et j'ai déjà traité ce problème
le code suivant compile:

Code:

---

1 2	eMCProp->element_MCPROP == r.getLocalName()

---

sachant que j'ai déjà un pointeur sur cette classe (eMCProp)

Salut

Code:

---

1 2 3 4 5 6 7 8 9

class MCE_MCProp { public: int status; void setAttribute( std::wstring, std::wstring); static std::wstring element_MCPROP; }; std::wstring MCE_MCProp::element_MCPROP = "valeur initiale";

---

et la ligne

Code:

---

MCE_Constantes::element_MCPROP == r.getLocalName()

---

fonctionnera. ça n'a pas de sens d'instancier la classe juste pour accéder à une valeur qui pourrait être statique comme c'est le cas dans la version java.

J'attire ton attention sur un point important : ce n'est pas parce que ça compile que ça fonctionne !

Merci de cette précision, j'ai été responsable de validation chez Alcatel
il faut que ca compile
il faut faire un bilan des symboles utilisé à la compilation
il faut passer l'édition de lien
et là on est à 50% d'avancement.
Les autres 50% c'est le test.

Et la conformité aux règles de codage qui dit de ne pas utiliser de membre d'instance qu'en un membre de classe suffit, c'est où ? :calim2:

ça marche mieux quand on sait ce qu'on fait, et qu'on compile ensuite

Sont bien sur justes... mais n'apportent rien au projet.
Dans le code il y a de nombreux commentaires qui expliquent ce qui doit être fait et les grammaires utilisées.
Probablement la stratégie de migration va évoluer. Les points d'entrés seront conservés ainsi que quelques partie d'implémentation et on va partir d'un framework c++
Je vous tiendrai au courant.