OVH Cloud OVH Cloud

XML en C++ : générer le xml et le parser

101 réponses
Avatar
noone
Bonjour,

je débute en C++ (j'ai fait un peu de C# avant)
L'avantage du C# était de pouvoir sérialiser facilement des objets c'est
à dire les stocker en XML.

Je ne sais pas trop comment m'y prendre en C++.

Quelle librairie utiliser (dans un projet utilisant déjà wxWidgets pour
l'interface graphique) ?

Pour les stocker je fais ceci :

// ===============================

#include <iostream> // pour cout
#include <fstream> // pour ofstream

using namespace std;

class Complexe {
public:
double x;
double y;

void Show()
{
cout << this->x << "+i*" << this->y << endl;
}
};

ostream & operator << (ostream & o,const Complexe & c)
{
return o
<< "<?xml version=\"1.0\"?>" << endl
<< "<Complexe" << " "
<< "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"
xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">" << endl
<< "<Re>" << c.x << "</Re>" << endl
<< "<Im>" << c.y << "</Im>" << endl
<< "</Complexe>" << endl;
}


int main()
{
Complexe cplx;
cplx.x=1;
cplx.y=2;

cplx.Show();

ofstream ofs("cplx.xml");

ofs << cplx << endl;
cout << cplx << endl;
}

// ======================


C'est un peu lourd à gérer non ?

Donc en clair avez vous une technique pour générer du xml simplement (et
avec fiabilité) ?

Comment parser ensuite ce fichier XML ?

Merci d'avance de vos réponses.

10 réponses

1 2 3 4 5
Avatar
Gabriel Dos Reis
"Arnaud Debaene" writes:

| James Kanze wrote:
|
| >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
|
| Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet d'échanger
| des données structurées complexes entre 2 programmes quelconques, même s'ils
| sont écrits avec des langages très différents (C# d'un côté et Perl de
| l'autre par exemple).

et jusque là quelle la différence avec mes propes formats ASCII?

| C'est ce qui est utilisé lourdement par les Web
| Services.

wouaou.

-- Gaby
Avatar
drkm
Gabriel Dos Reis writes:

et jusque là quelle la différence avec mes propes formats ASCII?


La mode ?

--drkm

Avatar
Michael
En espérant avoir été assez clair car je ne suis pas spécialiste.

Cordialement


Très clair, merci :-)

Avatar
Olivier Azeau
Gabriel Dos Reis wrote:
"Arnaud Debaene" writes:

| James Kanze wrote:
|
| >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
|
| Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet d'échanger
| des données structurées complexes entre 2 programmes quelconques, même s'ils
| sont écrits avec des langages très différents (C# d'un côté et Perl de
| l'autre par exemple).

et jusque là quelle la différence avec mes propes formats ASCII?

L'existence de parsers déja prêts ? (débuggés, optimisés...)

L'existence d'un mécanisme de validation via une DTD pour le contrôle
des erreurs ?
L'existence de langages adaptés pour traiter ces informations lors de
l'échange ? (XSLT)
L'idiome qui va permettre à un autre développeur de comprendre
immédiatement ce qui a été fait ?

Avatar
Gabriel Dos Reis
Olivier Azeau writes:

| Gabriel Dos Reis wrote:
| > "Arnaud Debaene" writes:
| > | James Kanze wrote:
| > | | >
| > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | >
| > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > domaines font plutôt exception.
| > | >
| > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > d'échanger | des données structurées complexes entre 2 programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)

Donc, c'est une question de parsers. J'utiliserais un autre mot que
« portabilité » pour décrire la chose, à moins bien sûr qu'on
me demande de travailler au département marketting.

| L'existence d'un mécanisme de validation via une DTD pour le contrôle
| des erreurs ?

Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.

| L'existence de langages adaptés pour traiter ces informations lors de
| l'échange ? (XSLT)

Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).

| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?

Mais cela peut être aussi le cas de mon propre format ASCII.

Bref.

-- Gaby
Avatar
Olivier Azeau
Gabriel Dos Reis wrote:
Olivier Azeau writes:

| Gabriel Dos Reis wrote:
| > "Arnaud Debaene" writes:
| > | James Kanze wrote:
| > | | >
| > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | >
| > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > domaines font plutôt exception.
| > | >
| > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > d'échanger | des données structurées complexes entre 2 programmes
| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).
| > et jusque là quelle la différence avec mes propes formats ASCII?
| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)

Donc, c'est une question de parsers. J'utiliserais un autre mot que
« portabilité » pour décrire la chose, à moins bien sûr qu'on
me demande de travailler au département marketting.


Quel autre mot ?
"Portabilité" ne décrit pas tout ce qu'on gagne à utiliser les parsers
XML existants mais je ne vois pas comment on pourrait nier le gain en
portabilité.

| L'existence d'un mécanisme de validation via une DTD pour le contrôle
| des erreurs ?

Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.


L'avantage c'est que ce n'est pas "mon" validateur DTD.
Moi je me contente d'écrire une DTD ou un schema et je laisse faire le
validateur existant...


| L'existence de langages adaptés pour traiter ces informations lors de
| l'échange ? (XSLT)

Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).


Je ne connais pas d'application C++ qui embarque un moteur awk ou perl
ou autre chose du même acabit.
Je ne dis pas que ça n'existe pas mais ce que "les gens" font en général
dans ce cas là, c'est utiliser une librairie de regexp et traiter la
partie transformation directement en C++

Je trouve pour ma part qu'embarquer un moteur XSLT dans du C++ est une
chose plus aisée, mais c'est peut-être une simple question de goût.

Ceci étant dit, quand il s'agit de traiter des données structurées
imbriquées, je souhaite bien du courage à celui qui veut faire ça avec
AWK. Pour ma part quand je fais du AWK aujourd'hui c'est toujours pour
mettre des données "anarchiques" en XML...


| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?

Mais cela peut être aussi le cas de mon propre format ASCII.


Chercher un développeur qui fait de l'échange de données en ASCII, c'est
un peu comme chercher un développeur qui fait du C++ avec des char* : il
faut qu'il ait été formé il y a un certain temps :-)

Avatar
Jean-Marc Bourguet
Olivier Azeau writes:

Gabriel Dos Reis wrote:
"Arnaud Debaene" writes:
| James Kanze wrote:
| | >
| >> L'intérêt de sérialiser en XML c'est que XML est portable
| >
| > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > peut effectivement parler d'une certaine portabilité. Mes ces
| > domaines font plutôt exception.
| >
| > Dans la pratique, il y a encore peu de cas où XML se justifie.
| | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
d'échanger | des données structurées complexes entre 2 programmes
quelconques, même s'ils | sont écrits avec des langages très différents
(C# d'un côté et Perl de | l'autre par exemple).
et jusque là quelle la différence avec mes propes formats ASCII?

L'existence de parsers déja prêts ?



J'ai plus vite fait d'ecrire un parseur pour un format que j'aurais
defini (si le XML est approprie, des sexp a la lisp le sont aussi et
c'est beaucoup, beaucoup plus simple, s'il faut se contraindre pour
passer dans le moule XML, il y a plus simple) que de demander au
departement legal s'il est possible d'utiliser un parseur XML
quelconque. Sans parler du temps pour apprendre a s'en servir.

(débuggés, optimisés...)


Vu l'usine a gaz qu'est XML, un parseur XML optimise est moins
efficace qu'un parseur vite fait bien fait pour un autre format.

Le seul avantage, c'est si le DTD est deja definit par ailleurs et pas
controle par un concurrent. Mais ce n'est pas un avantage d'XML,
c'est un avantage d'un format definit. Et la nature d'XML en fait un
format mal adapte a autre chose que la communication entre programmes
quasiment independant; donc on aura vraissemblablement de toute facon
un format interne en plus.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org


Avatar
adebaene
Gabriel Dos Reis wrote:

| > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD)
permet

| > d'échanger | des données structurées complexes entre 2
programmes

| > quelconques, même s'ils | sont écrits avec des langages très
| > différents (C# d'un côté et Perl de | l'autre par exemple).

| > et jusque là quelle la différence avec mes propes formats
ASCII?

| >
| L'existence de parsers déja prêts ? (débuggés, optimisés...)

Donc, c'est une question de parsers.
C'est surtout une question de standardisation du format parsé (et de

"correctness" des parsers utilisés), et donc oui ca a un impact sur la
portabilité AMHA, même si ce n'est pas de la portabilité de code C++
directement.


| L'existence d'un mécanisme de validation via une DTD pour le
contrôle

| des erreurs ?

Mais cela dépend de mon propre format ASCII : est-il plus simple
d'utiliser ton validateur DTD que mon propre vérificateur de format
qui eput Être de loin plus simple selon mon propre format ASCII ?
Mon propre vérificateur peut être aussi auto-correcteur ou non
redondant.
Oui, yapluka l'écrire, et probablement le refaire (ou le modifier)

pour chaque nouveau projet, si les contraintes sont différentes...


| L'existence de langages adaptés pour traiter ces informations lors
de

| l'échange ? (XSLT)

Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
Perl, ...).
On parle de C++, non ?



| L'idiome qui va permettre à un autre développeur de comprendre
| immédiatement ce qui a été fait ?

Mais cela peut être aussi le cas de mon propre format ASCII.


Entre ton format ASCII maison (aussi bien conçu soit-il), et un
standard du W3C, il n'y a pas photo pour ce qui est de la facilité de
trouver un développeur compétent et capable de réutiliser facilement
le format...

Bref.
Ta réaction me fait un peu penser aux gens qui disent "à quoi ca sert

std::vector, je peux très bien faire mes tableaux à la main". Certes
on peut tout faire à la main, maintenant quand est-ce que c'est
rentable/intéressant, et quand est-ce qu'on a intérêt a choisir une
solution "standard", éprouvée et déjà faite...

Arnaud

Avatar
Gabriel Dos Reis
Olivier Azeau writes:

Est-ce que tu peux arrêter de systématiquement moglifier mes
« citations » ? ou est-ce un nouvelle technique de confusion ?


| Gabriel Dos Reis wrote:
| > Olivier Azeau writes:
| > | Gabriel Dos Reis wrote:
| > | > "Arnaud Debaene" writes:
| > | > | James Kanze wrote:
| > | > | | >
| > | > | >> L'intérêt de sérialiser en XML c'est que XML est portable
| > | > | >
| > | > | > Pas vraiment. Le syntaxe de base est portable. Mais ça ne suffit
| > | > | > pas ; il faut aussi que les deux côtés soient d'accord sur le
| > | > | > DTD. Dans les domaines où il y a un DTD standard prédéfini, on
| > | > | > peut effectivement parler d'une certaine portabilité. Mes ces
| > | > | > domaines font plutôt exception.
| > | > | >
| > | > | > Dans la pratique, il y a encore peu de cas où XML se justifie.
| > | > | | Je ne suis pas tout à fait d'accord : XML (avec un DTD) permet
| > | > d'échanger | des données structurées complexes entre 2 programmes
| > | > quelconques, même s'ils | sont écrits avec des langages très
| > | > différents (C# d'un côté et Perl de | l'autre par exemple).
| > | > et jusque là quelle la différence avec mes propes formats ASCII?
| > | >
| > | L'existence de parsers déja prêts ? (débuggés, optimisés...)
| > Donc, c'est une question de parsers. J'utiliserais un autre mot que
| > « portabilité » pour décrire la chose, à moins bien sûr qu'on me
| > demande de travailler au département marketting.
|
| Quel autre mot ?

Aucune idée. <g>

[...]

| > | L'existence de langages adaptés pour traiter ces informations lors
| > de
| > | l'échange ? (XSLT)
| > Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
| > Perl, ...).
|
| Je ne connais pas d'application C++ qui embarque un moteur awk ou perl
| ou autre chose du même acabit.

mais cela en dit plus sur tes connaissances d'applications que tu ne
connais pas que l'omnipertinence de XML que tu essaies d'avancer.

| Je ne dis pas que ça n'existe pas mais ce que "les gens" font en
| général dans ce cas là, c'est utiliser une librairie de regexp et
| traiter la partie transformation directement en C++

Aha.

| Je trouve pour ma part qu'embarquer un moteur XSLT dans du C++ est une
| chose plus aisée, mais c'est peut-être une simple question de goût.

Très certainement.

| Ceci étant dit, quand il s'agit de traiter des données structurées
| imbriquées, je souhaite bien du courage à celui qui veut faire ça avec
| AWK. Pour ma part quand je fais du AWK aujourd'hui c'est toujours pour
| mettre des données "anarchiques" en XML...
|
| > | L'idiome qui va permettre à un autre développeur de comprendre
| > | immédiatement ce qui a été fait ?
| > Mais cela peut être aussi le cas de mon propre format ASCII.
|
| Chercher un développeur qui fait de l'échange de données en ASCII,
| c'est un peu comme chercher un développeur qui fait du C++ avec des
| char* : il faut qu'il ait été formé il y a un certain temps :-)

N'est-ce pas ? Dan les domaines où j'interviens, on cherche d'abord
des gens du domaine d'application et qui savent programmer.
Ton analogie est peut-être fondée, mais dans les domaines où
j'interviens, ou les gens que je connais qui font des trucs comme ça,
ils n'ont pas eu de formation particulière en matière d'échanges
ASCII.


-- Gaby
Avatar
Gabriel Dos Reis
writes:

[...]

| > | L'existence d'un mécanisme de validation via une DTD pour le
| contrôle
| > | des erreurs ?
| >
| > Mais cela dépend de mon propre format ASCII : est-il plus simple
| > d'utiliser ton validateur DTD que mon propre vérificateur de format
| > qui eput Être de loin plus simple selon mon propre format ASCII ?
| > Mon propre vérificateur peut être aussi auto-correcteur ou non
| > redondant.
| Oui, yapluka l'écrire, et probablement le refaire (ou le modifier)
| pour chaque nouveau projet, si les contraintes sont différentes...

non seulement « yapluka » mais je parle de cas concrets où
(1) l'artillerie XML a été déployée -- probablement parce que
quelqu'un a du avoir été intoxiqué par la sorte de propagande
que je discerne dans ce thread ;

(2) après des mois d'utilisation (et d'évolution du logiciel), il
a été décidé (sur la base des expériences) d'utiliser un format
ASCII « maison », ma foi assez simple.

Le résultat du (2) a, dans les cas que je connais, été plus rentable
qu'une insistance fanatique dans la machinerie XML.

| > | L'existence de langages adaptés pour traiter ces informations lors
| de
| > | l'échange ? (XSLT)
| >
| > Mais, cela peut être aussi le cas de mon propre format ASCII (AWK,
| > Perl, ...).
| On parle de C++, non ?

Oui.

| > | L'idiome qui va permettre à un autre développeur de comprendre
| > | immédiatement ce qui a été fait ?
| >
| > Mais cela peut être aussi le cas de mon propre format ASCII.
|
| Entre ton format ASCII maison (aussi bien conçu soit-il), et un
| standard du W3C, il n'y a pas photo pour ce qui est de la facilité de
| trouver un développeur compétent et capable de réutiliser facilement
| le format...

tu ne crois pas si bien dire : dans les cas cités ci-haut, ce sont des
« développeurs » que je place beaucoup plus compétents que moi et ils
ont préféré quelque chose contraire à ton théorème.

| > Bref.
| Ta réaction me fait un peu penser aux gens qui disent "à quoi ca sert
| std::vector, je peux très bien faire mes tableaux à la main". Certes

Je trouve malheureux que tu n'aies vu que le bout du doigt lorsque je
montrais la lune.

| on peut tout faire à la main, maintenant quand est-ce que c'est
| rentable/intéressant, et quand est-ce qu'on a intérêt a choisir une
| solution "standard", éprouvée et déjà faite...

Mais c'est quoi la solution standard ici ?

Analogie pour analogie, c'est comme si tu me disais que je dois
systématiquement choisir d'écrire mes programmes en C++, en place et
lieu de Python ou Perl parce que C++ a un standard ISO.

-- Gaby
1 2 3 4 5