OVH Cloud OVH Cloud

C++ interface XML

16 réponses
Avatar
Ignace
Bonjour

Je désire réaliser une application en C++ qui manipule de gros fichiers de
configuration en XML (en local : pas un serveur).
Je travaille sur VS NET pour C++.

J'ai travaillé avec les DOM sous VB.
J'ai trouvé (beaucoup) d'exemples clairs en C#. Que j'ai compilé avec le NET
SDK.

Mon objectif est de réaliser du code C++

Pas moyen de porter sous C++ (includes, namespace...). Comment configurer
mon projet, quelles entêtes...
Un exemple ?

Est-il posible de porter du code C# en C++ ? Et utiliser xsd.exe ?

Quelles précautions à prendre pour que mon code soit le "plus multi plate
forme possible" (Linux et Unix).
(Isoler les accès bas niveau).


Merci

--
Ignace

10 réponses

1 2
Avatar
Seb
"Ignace" a écrit dans le message news:
4003e609$0$29062$
Bonjour



[ ... ]

Quelles précautions à prendre pour que mon code soit le "plus multi
plate forme possible" (Linux et Unix).
(Isoler les accès bas niveau).


Merci



Pour le multi-plate forme pourquoi ne pas s'orienter directement vers un
compilateur qui le soit : gcc par exemple

Sebastien
Avatar
Ambassadeur Kosh
> Pas moyen de porter sous C++ (includes, namespace...). Comment configurer
mon projet, quelles entêtes...
Un exemple ?



le namespace System.Xml est utilisable directement en C++ managé.

using namespace System.Xml ;

XmlDocument *document = new XmlDocument() ;
...

Est-il posible de porter du code C# en C++ ?



oui, avec tes petits doigts musclés, et tu refais tout. serieux, quel est
l'interet de reprendre du code C# alors qu'il est directement utilisable
sous C++ ? c'est le but du code managé. éviter les portages, bidouillages,
recompils et autres bricolages qui font perdre un temps conséquent et amene
des erreurs en pagaille.
la rapidité ? bof. perfs équivalentes pour le managé.
l'unicité du langage ? bof. apprendre le C#, ça prend 20 minutes pour un
gars qui connait l'Objet.

si vraiment c'est crucial, tu as un outils qui s'appelle reflector qui peut
faire ça. son but est de prendre un assembly (dll) est d'en fournir le code
source dans n'importe le langage .Net choisi.

Et utiliser xsd.exe ?



oui.

Quelles précautions à prendre pour que mon code soit le "plus multi plate
forme possible" (Linux et Unix).
(Isoler les accès bas niveau).



la je peux pas te dire... normallement, le framework est "censé" garantir
ça. faut regarder du côté de mono...
Avatar
Seb
"Ambassadeur Kosh" a écrit dans le message
news: bu0u44$imp$
Pas moyen de porter sous C++ (includes, namespace...). Comment
configurer mon projet, quelles entêtes...
Un exemple ?



le namespace System.Xml est utilisable directement en C++ managé.

using namespace System.Xml ;

XmlDocument *document = new XmlDocument() ;
...

Est-il posible de porter du code C# en C++ ?



oui, avec tes petits doigts musclés, et tu refais tout. serieux, quel
est l'interet de reprendre du code C# alors qu'il est directement
utilisable sous C++ ?



Je ne connais pas bien le C# mais je suis loin d'etre certain de la
compatibilité dans les deux sens (sans quoi ils n'auraient pas inventé un
nouveau langage, ils auraient conservés le C++)


[ ... ]


la je peux pas te dire... normallement, le framework est "censé"
garantir ça. faut regarder du côté de mono...



Je ne savais pas que tu pouvais faire un truc linux avec du microsoft ;-)
Avatar
Ambassadeur Kosh
> Je ne connais pas bien le C# mais je suis loin d'etre certain de la
compatibilité dans les deux sens (sans quoi ils n'auraient pas inventé un
nouveau langage, ils auraient conservés le C++)



t'es passé à côté de quelque chose d'énorme.
microsoft.public.fr.dotnet histoire de commencer à réaliser.

la je peux pas te dire... normallement, le framework est "censé"
garantir ça. faut regarder du côté de mono...


Je ne savais pas que tu pouvais faire un truc linux avec du microsoft ;-)



tu serais pas de la famille d'un certain
par hasard ?
Avatar
Seb
"Ambassadeur Kosh" a écrit dans le message news:
bu15c0$bab$
> Je ne connais pas bien le C# mais je suis loin d'etre certain de la
> compatibilité dans les deux sens (sans quoi ils n'auraient pas inventé


un
> nouveau langage, ils auraient conservés le C++)

t'es passé à côté de quelque chose d'énorme.
microsoft.public.fr.dotnet histoire de commencer à réaliser.




Je ne veux pas troller, mais en vrac et vite fais :
-comment appeler en C# un destructeur explicitement ?
- "string fileName = @"c:temptest.txt" " c'est compatible C++ C# ?

Tout ça pour dire que si on souhaite faire un truc multi plate forme le C#
n'est pas à mon avis la solution



>> la je peux pas te dire... normallement, le framework est "censé"
>> garantir ça. faut regarder du côté de mono...
> Je ne savais pas que tu pouvais faire un truc linux avec du microsoft


;-)

tu serais pas de la famille d'un certain



par hasard ?





Non.
Avatar
Arnaud Debaene
Seb wrote:
"Ambassadeur Kosh" a écrit dans le message
news: bu15c0$bab$
Je ne connais pas bien le C# mais je suis loin d'etre certain de la
compatibilité dans les deux sens (sans quoi ils n'auraient pas
inventé un nouveau langage, ils auraient conservés le C++)






Qu'est ce que tu entends par "compatibles" exactement? Il est évident que
les sources ne sont pas compatibles et que le C++ a des capacités
d'expressivité supplémentaires (mais le C# propose aussi des choses
impossibles en C++). Par contre, une assembly écrite en C++ managé (un
sous-ensemble du C++ qui peut appeler des méthodes C++ "normal") peut
interopérer avec une assembly C#. Et quand je dis interopérer, je veux dire
qu'une classe C++ managée peut dériver d'une classe C# (et vice-versa).


Je ne veux pas troller, mais en vrac et vite fais :
-comment appeler en C# un destructeur explicitement ?


On implémente IDisposable et on appelle Dispose. La mémoire est libérée plus
tard par le GC.

Et au fait... tu appelles souvent un destructeur explicitement en C++? ....
(je SAIS qu'on peut et doit le faire parfois, mais ce sont des cas
extrêmement rares).

- "string fileName = @"c:temptest.txt" " c'est compatible C++ C# ?


Bien sûr que non, mais tu écrits soit en C++, soit en C#, pas les 2 en même
temps! Par contre les binaires C# et C++ managé sont compatibles et
interopérables.

Tout ça pour dire que si on souhaite faire un truc multi plate forme
le C# n'est pas à mon avis la solution


Pourquoi??? s'il y a un compilateur C# sur ta plate-forme cible (cf le
projet Mono), le problème est exactement le même qu'en C++.

Une autre solution si tu veux faire du C++ et ne pas t'embarasser avec le
framework .NET, c'est d'utiliser un parser XML C++ qui soit porté sur tes
plates-formes cibles. Xerces devrait faire l'affaire dans ton cas
(http://xml.apache.org/xerces-c/index.html). Il a des extensions pour faire
des choses plus avancées, comme Xalan pour parser et "processer" du XSL. Par
contre, le modèle objet de manipulation n'est évidemment pas le même.

Arnaud
Avatar
Ignace
"Seb" a écrit dans le message de
news:bu0rdq$pil$
"Ignace" a écrit dans le message news:
4003e609$0$29062$
> Bonjour
>
[ ... ]
>
> Quelles précautions à prendre pour que mon code soit le "plus multi
> plate forme possible" (Linux et Unix).
> (Isoler les accès bas niveau).
>
>
> Merci

Pour le multi-plate forme pourquoi ne pas s'orienter directement vers un
compilateur qui le soit : gcc par exemple




Je raboute des morceaux issus de plusieurs projets.
Mon objectif est d'appliquer un algorithme de traitement d'image.
Je m'interface 'en aveugle' (plugin) dans un flux vidéo qui me transmet des
images séquentiellement.
Ce plugin est un (gros) projet écrit dans du M$ (DirectX et tout et tout),
dont je ne suis pas maitre.
J'ai juste une API à respecter.

Je dois donc développer sous VS de façon à ce que mon projet "enveloppe" ne
soit pas chamboulé.
Donc pas gcc (ATL, MFCs, MC++, trop de configs...).
Par contre, ce projet "enveloppe" sera tôt ou tard porté (linux/unix). Mais
pas par moi.
Je dois veiller à ce que le portage de ma partie de code soit aisé.

C'est ce qui justifie notamment un format de sérialisation texte xml, que
j'ai déjà utilisé dans d'autres environnements (vb, xslt).

Voila.

Merci pour vos conseils. Je constate qu'il y a une part de "philosophie"
importante autour des technos .NET : il va faloir que je lève le nez de mon
labo... :)

Merci, ainsi qu'aux autres contributeurs avertis.
J'applique vos conseils dès demain (ma machine de développement ne possède
pas de messagerie : parano sécuritaire...).

-- Ignace
Avatar
Ignace
"Ambassadeur Kosh" a écrit dans le message de
news:bu0u44$imp$
> Pas moyen de porter sous C++ (includes, namespace...). Comment


configurer
> mon projet, quelles entêtes...
> Un exemple ?

le namespace System.Xml est utilisable directement en C++ managé.

using namespace System.Xml ;




Il me semble que ça ne marche pas (erreur au link).
J'ai un problème : (VS .NET pour C++), la complétion ne fonctionne pas bien.
Je m'attendait à un comportement intuitif de l'IDE ("System."->liste de
completion).
Mais là, rien.
A moins que cette analyse soit compliquée.

J'ai vaguement l'impression que mon IDE est dans les choux.

XmlDocument *document = new XmlDocument() ;
...

> Est-il posible de porter du code C# en C++ ?

oui, avec tes petits doigts musclés, et tu refais tout. serieux, quel est
l'interet de reprendre du code C# alors qu'il est directement utilisable
sous C++ ? c'est le but du code managé. éviter les portages, bidouillages,
recompils et autres bricolages qui font perdre un temps conséquent et


amene
des erreurs en pagaille.
la rapidité ? bof. perfs équivalentes pour le managé.



Oui, mais mon appli ne fait pas que ça : elle traite de la vidéo image/image
(après mes accès xml en initialisation). Le fait que j'utilise le "managé"
ne va t'il pas ralentir le reste de l'application (qui n'en a pas besoin) ?
Franchement, le garbage collector, je sais m'en passer.

l'unicité du langage ? bof. apprendre le C#, ça prend 20 minutes pour un
gars qui connait l'Objet.




Oui oui, c# semble très "sain". Un peu java sur les bords. Je ne m'en plains
pas :
le pointeur sur la structure de pointeurs qui identifient une table de
fonctions qui retournent un pointeur (void).
...j'ai donné !

Par contre le portage c#->c++ (non managé) ne me semble pas trivial...

si vraiment c'est crucial, tu as un outils qui s'appelle reflector qui


peut
faire ça. son but est de prendre un assembly (dll) est d'en fournir le


code
source dans n'importe le langage .Net choisi.

> Et utiliser xsd.exe ?

oui.

> Quelles précautions à prendre pour que mon code soit le "plus multi


plate
> forme possible" (Linux et Unix).
> (Isoler les accès bas niveau).

la je peux pas te dire... normallement, le framework est "censé" garantir
ça. faut regarder du côté de mono...



Qu'est ce que "mono" ? (pardon si idiot)

Merci

--
Ignace
Avatar
adebaene
"Ignace" wrote in message news:<40047aae$0$7132$...

Qu'est ce que "mono" ? (pardon si idiot)



Un portage du framework .NET et du compilateur C# sur Linux. Voir
http://www.go-mono.com/

Arnaud
Avatar
Ambassadeur Kosh
> Il me semble que ça ne marche pas (erreur au link).



// Il s'agit du fichier projet principal pour le projet d'application VC++
// généré en utilisant un Assistant Application.

#include "stdafx.h"

#using <mscorlib.dll>
#using <system.xml.dll>

using namespace System;
using namespace System::Xml;

int _tmain()
{
System::Xml::XmlDocument *p = new System::Xml::XmlDocument() ;
p->LoadXml("<test/>") ;
Console::WriteLine(S"Hello World");
return 0;
}

ca compile, ça link, ça s'execute.
c'est un projet console C++ Managé de base.
si ça roule pas, c'est ton Vs qui pete un cable.


J'ai un problème : (VS .NET pour C++), la complétion ne fonctionne pas


bien.
pourtant, dans certaines "formes" d'écritures, elle marche à merveille.
il faudrait etre plus precis sur ce qui se passe.


J'ai vaguement l'impression que mon IDE est dans les choux.


possible

Oui, mais mon appli ne fait pas que ça : elle traite de la vidéo


image/image
(après mes accès xml en initialisation). Le fait que j'utilise le "managé"
ne va t'il pas ralentir le reste de l'application (qui n'en a pas besoin)


?

managé ne veux pas dire perfs pitoyables. si tu n'as pas confiance, sépare
les deux mondes. écrit toi une classe __gc d'interfacage, une classe normale
pour l'implantation de l'autre. le beurre et l'argent du beurre.

ensuite, amuses toi à comparer en rendant ta classe d'implantation __gc.
et utilises dedans des std::vector, std::toutcequetuveux, histoire de voir.
tu peux aussi regarder du côté du code generé et comparer.

profite en pour t'appuyer sur un profiler. ça permet de ne pas tirer de
conclusions (trop) erronées sur ce qui pompe du temps, et ça peut contribuer
à comprendre ce qui change, et ce qui ne change pas avec le concept des
classes managées (__gc)

Franchement, le garbage collector, je sais m'en passer.



cette phrase a un parfum de testosterone :o)
les Cmens n'ont pas besoin d'objet, et d'un compilateur qui vérifie les
types, ils savent blabla blabla blabla etc.
bon, l'objet est infiniment superieur. considere que le gc est un apport
formel du même ordre.

> l'unicité du langage ? bof. apprendre le C#, ça prend 20 minutes pour un
> gars qui connait l'Objet.
Oui oui, c# semble très "sain". Un peu java sur les bords. Je ne m'en


plains
pas



c'est clair. et avec ce qui va arriver (genre les generics), ça va devenir
de plus en plus interessant.

le pointeur sur la structure de pointeurs qui identifient une table de
fonctions qui retournent un pointeur (void).
...j'ai donné !



:o)

Par contre le portage c#->c++ (non managé) ne me semble pas trivial...



bof. pourtant, ça me semble assez "direct" comme traduction. mais c'est
pareil, il faut exprimer ce que tu souhaites voir et ce que tu ne souhaite
pas voir comme bonnes propriétés dans le resultat. si c'est transformer tout
seul des Algos NP en Algos P, je sais pas si on peut encore appeller ça du
portage.

mais pourquoi porter quand on peut utiliser directement ? qu'est ce qui est
écrit en C# et qui ne te conviens pas ?
tu as des fonctionalités en C# qui tournent trop lentement ? le but de la
manoeuvre, c'est que chacun écrit dans son langage preferé et hop,
interoperabilité. du multi culturel.

pour ma part, je ne trouve pas le C# si lent que ça. j'ai des optims qui
tournent plein pot et qui sont écrites en C#. ça a certaines vertus, faire
des objets. par exemple celle de ne pas occuper la machine a faire des
copies en pagaille. mais bon, la encore, faut profiler au cas par cas.


Qu'est ce que "mono" ? (pardon si idiot)



c'est l'implantation sous Unix du Framework. dans l'avenir (s'il est
clément), le ciel sera radieu, et comme Java, les exe .Net d'une machine
tourneront sur une autre sans se soucier de rien. voila. Arnaud ou Quentin
pourraient t'en dire un peu plus.

je te conseille vivement d'aller jetter un oeil sur le forum
microsoft.public.fr.dotnet.

voila voila.
1 2