Gagnant en terme de quoi? Je parlais de la facilité à trouver quelqu'un de compétent pour reprendre le code / réutiliser les fichiers correspondants. Je ne pense pas que beaucoup de gens soient compétents en théorie des langages, chose qu'il faut voir un minimum pour gérer soit même un parser.
Ça dépend. Un format ASCII ligne simple ne demande pas de compétences particulières. Des std::getline() et une analyse de chaque ligne peuvent suffire. C'est du moins bien plus simple que d'apprendre à utiliser correctement un parseur XML.
Bien que SAX serait sans doute dans un tel cas assez simple à mettre en oeuvre, de même que la DTD ou le schéma, pour ne pas avoir à valider soi-même le format dans les gestionnaires SAX.
--drkm
adebaene@club-internet.fr writes:
Gagnant en terme de quoi? Je parlais de la facilité à trouver
quelqu'un de compétent pour reprendre le code / réutiliser les
fichiers correspondants. Je ne pense pas que beaucoup de gens soient
compétents en théorie des langages, chose qu'il faut voir un minimum
pour gérer soit même un parser.
Ça dépend. Un format ASCII ligne simple ne demande pas de
compétences particulières. Des std::getline() et une analyse de
chaque ligne peuvent suffire. C'est du moins bien plus simple que
d'apprendre à utiliser correctement un parseur XML.
Bien que SAX serait sans doute dans un tel cas assez simple à mettre
en oeuvre, de même que la DTD ou le schéma, pour ne pas avoir à
valider soi-même le format dans les gestionnaires SAX.
Gagnant en terme de quoi? Je parlais de la facilité à trouver quelqu'un de compétent pour reprendre le code / réutiliser les fichiers correspondants. Je ne pense pas que beaucoup de gens soient compétents en théorie des langages, chose qu'il faut voir un minimum pour gérer soit même un parser.
Ça dépend. Un format ASCII ligne simple ne demande pas de compétences particulières. Des std::getline() et une analyse de chaque ligne peuvent suffire. C'est du moins bien plus simple que d'apprendre à utiliser correctement un parseur XML.
Bien que SAX serait sans doute dans un tel cas assez simple à mettre en oeuvre, de même que la DTD ou le schéma, pour ne pas avoir à valider soi-même le format dans les gestionnaires SAX.
--drkm
drkm
writes:
Seulement, je ne connais pas de façon à gérer ces identificateurs de façon générique.
J'ai toujours cru, peut-être naïvement, que cela était suffisant, éventuellement en préfixant la chaîne si l'adresse de l'objet peut être utilisée dans différents identifiants.
--drkm
kanze@gabi-soft.fr writes:
Seulement, je ne connais pas de façon à gérer ces
identificateurs de façon générique.
J'ai toujours cru, peut-être naïvement, que cela était suffisant,
éventuellement en préfixant la chaîne si l'adresse de l'objet peut
être utilisée dans différents identifiants.
J'ai toujours cru, peut-être naïvement, que cela était suffisant, éventuellement en préfixant la chaîne si l'adresse de l'objet peut être utilisée dans différents identifiants.
--drkm
Loïc Joly
wrote:
Loïc Joly wrote:
Un parseur XML demande lui de modifier : - La classe - Les fichiers de données - Le code qui parse - Les schéma Ce qui en exploitation se traduit par un programme et deux fichiers.
Sauf que avec les langages supportant l'introspection, le schéma est généré par une moulinette à partir de la classe. Il y a même de cas où il n'y a pas besoin de générer explicitement le schéma : la mécanisme de sérialisation le fait pour toi à la volée selon les besoins.
Si tu utilises une génération à la volée, c'est que tu n'est pas intéressé par respecter un format de fichier défini externement. Parce que sinon, ton code va devoir avoir un certain nombre d'absurdités... Par exemple, l'ordre des champs dans ta classe dans ton code va dépendre de la spec du fichier.
Et ce qui sert dans ce cas là, c'est une bonne sérialisation aidée par de l'introspection. Ce qui nous ramène au sujet initial. Que le format généré soit XML ou autre n'a pas vraiment d'importance dans ce cas.
[...]
Pour moi, l'un des gros avantages de XML est qu'il est souple et qu'il peut être utilisé de manière "crade" : je n'utilise un schéma que si je veux effectivement valider de manière stricte un document.
Comme je le disais, le niveau de vérification apporté par les schémas n'a rien de strict pour moi.
-- Loïc
adebaene@club-internet.fr wrote:
Loïc Joly wrote:
Un parseur XML demande lui de modifier :
- La classe
- Les fichiers de données
- Le code qui parse
- Les schéma
Ce qui en exploitation se traduit par un programme et deux fichiers.
Sauf que avec les langages supportant l'introspection, le schéma est
généré par une moulinette à partir de la classe. Il y a même de
cas où il n'y a pas besoin de générer explicitement le schéma : la
mécanisme de sérialisation le fait pour toi à la volée selon les
besoins.
Si tu utilises une génération à la volée, c'est que tu n'est pas
intéressé par respecter un format de fichier défini externement. Parce
que sinon, ton code va devoir avoir un certain nombre d'absurdités...
Par exemple, l'ordre des champs dans ta classe dans ton code va dépendre
de la spec du fichier.
Et ce qui sert dans ce cas là, c'est une bonne sérialisation aidée par
de l'introspection. Ce qui nous ramène au sujet initial. Que le format
généré soit XML ou autre n'a pas vraiment d'importance dans ce cas.
[...]
Pour moi, l'un des gros avantages de XML est qu'il est souple et qu'il
peut être utilisé de manière "crade" : je n'utilise un schéma que
si je veux effectivement valider de manière stricte un document.
Comme je le disais, le niveau de vérification apporté par les schémas
n'a rien de strict pour moi.
Un parseur XML demande lui de modifier : - La classe - Les fichiers de données - Le code qui parse - Les schéma Ce qui en exploitation se traduit par un programme et deux fichiers.
Sauf que avec les langages supportant l'introspection, le schéma est généré par une moulinette à partir de la classe. Il y a même de cas où il n'y a pas besoin de générer explicitement le schéma : la mécanisme de sérialisation le fait pour toi à la volée selon les besoins.
Si tu utilises une génération à la volée, c'est que tu n'est pas intéressé par respecter un format de fichier défini externement. Parce que sinon, ton code va devoir avoir un certain nombre d'absurdités... Par exemple, l'ordre des champs dans ta classe dans ton code va dépendre de la spec du fichier.
Et ce qui sert dans ce cas là, c'est une bonne sérialisation aidée par de l'introspection. Ce qui nous ramène au sujet initial. Que le format généré soit XML ou autre n'a pas vraiment d'importance dans ce cas.
[...]
Pour moi, l'un des gros avantages de XML est qu'il est souple et qu'il peut être utilisé de manière "crade" : je n'utilise un schéma que si je veux effectivement valider de manière stricte un document.
Comme je le disais, le niveau de vérification apporté par les schémas n'a rien de strict pour moi.
-- Loïc
drkm
Loïc Joly writes:
Comme je le disais, le niveau de vérification apporté par les schémas n'a rien de strict pour moi.
Qu'entends-tu par là ?
--drkm
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
Comme je le disais, le niveau de vérification apporté par les schémas
n'a rien de strict pour moi.
Comme je le disais, le niveau de vérification apporté par les schémas n'a rien de strict pour moi.
Qu'entends-tu par là ?
--drkm
Olivier Azeau
wrote:
Gabriel Dos Reis wrote:
[...]
| ... mais parce que l'on va y trouver toute une panoplie de | services que l'on aurait bien du mal à réécrire soi même.
*si* ces services *conviennent* à l'application donnée. Ce qui est loin d'être acquis et c'est bien l'objet du débat (je parle toujours de XML et non de la STL).
Mais pourquoi pas parler de la STL aussi. J'écris encore : int i = 0 ; et non : std::vector< int > i( 1, 0 ) ; Je n'utilise la STL que quand il fait quelque chose dont j'ai besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou parce que c'est in.
Le problème que je vois avec le XML, en fait, c'est qu'il essaie de fournir std::map sans vouloir même admettre l'existance possible de std::vector ni d'int.
Là, je ne comprends pas. Un int n'existe jamais seul et quoi de plus simple de le mettre comme attribut d'un noeud xml. Les attributs sont justement là pour ça : des données simples. Idem pour les vecteurs. La faculté de mettre en séquence plusieurs noeud de même type, qu'est-ce que c'est sinon un vecteur (ou une liste) ?
C'est justement toute la puissance d'XML de pouvoir prendre en charge simplement les choses simples et de manière plus complexe les choses plus complexes (et de passer de l'une à l'autre sans tout casser).
Quoi de plus simple pour sérialiser: struct X { int a; };
que : <X a='13'/> ?
Et si on veut du complexe, ce n'est pas bcp plus cher. Par exemple : struct X { std::vector<std::vector<int>> b; };
Maintenant, comment faire la même chose en ASCII ? Et surtout coder en C++ le parser associé ?
kanze@gabi-soft.fr wrote:
Gabriel Dos Reis wrote:
[...]
| ... mais parce que l'on va y trouver toute une panoplie de
| services que l'on aurait bien du mal à réécrire soi même.
*si* ces services *conviennent* à l'application donnée. Ce qui
est loin d'être acquis et c'est bien l'objet du débat (je
parle toujours de XML et non de la STL).
Mais pourquoi pas parler de la STL aussi. J'écris encore :
int i = 0 ;
et non :
std::vector< int > i( 1, 0 ) ;
Je n'utilise la STL que quand il fait quelque chose dont j'ai
besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou
parce que c'est in.
Le problème que je vois avec le XML, en fait, c'est qu'il essaie
de fournir std::map sans vouloir même admettre l'existance
possible de std::vector ni d'int.
Là, je ne comprends pas.
Un int n'existe jamais seul et quoi de plus simple de le mettre comme
attribut d'un noeud xml. Les attributs sont justement là pour ça : des
données simples.
Idem pour les vecteurs. La faculté de mettre en séquence plusieurs noeud
de même type, qu'est-ce que c'est sinon un vecteur (ou une liste) ?
C'est justement toute la puissance d'XML de pouvoir prendre en charge
simplement les choses simples et de manière plus complexe les choses
plus complexes (et de passer de l'une à l'autre sans tout casser).
Quoi de plus simple pour sérialiser:
struct X
{
int a;
};
que : <X a='13'/> ?
Et si on veut du complexe, ce n'est pas bcp plus cher. Par exemple :
struct X
{
std::vector<std::vector<int>> b;
};
| ... mais parce que l'on va y trouver toute une panoplie de | services que l'on aurait bien du mal à réécrire soi même.
*si* ces services *conviennent* à l'application donnée. Ce qui est loin d'être acquis et c'est bien l'objet du débat (je parle toujours de XML et non de la STL).
Mais pourquoi pas parler de la STL aussi. J'écris encore : int i = 0 ; et non : std::vector< int > i( 1, 0 ) ; Je n'utilise la STL que quand il fait quelque chose dont j'ai besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou parce que c'est in.
Le problème que je vois avec le XML, en fait, c'est qu'il essaie de fournir std::map sans vouloir même admettre l'existance possible de std::vector ni d'int.
Là, je ne comprends pas. Un int n'existe jamais seul et quoi de plus simple de le mettre comme attribut d'un noeud xml. Les attributs sont justement là pour ça : des données simples. Idem pour les vecteurs. La faculté de mettre en séquence plusieurs noeud de même type, qu'est-ce que c'est sinon un vecteur (ou une liste) ?
C'est justement toute la puissance d'XML de pouvoir prendre en charge simplement les choses simples et de manière plus complexe les choses plus complexes (et de passer de l'une à l'autre sans tout casser).
Quoi de plus simple pour sérialiser: struct X { int a; };
que : <X a='13'/> ?
Et si on veut du complexe, ce n'est pas bcp plus cher. Par exemple : struct X { std::vector<std::vector<int>> b; };
Maintenant, comment faire la même chose en ASCII ? Et surtout coder en C++ le parser associé ?
Gabriel Dos Reis
Olivier Azeau writes:
| wrote: | > Gabriel Dos Reis wrote: | > [...] | > | >>| ... mais parce que l'on va y trouver toute une panoplie de | >>| services que l'on aurait bien du mal à réécrire soi même. | > | >>*si* ces services *conviennent* à l'application donnée. Ce qui | >>est loin d'être acquis et c'est bien l'objet du débat (je | >>parle toujours de XML et non de la STL). | > Mais pourquoi pas parler de la STL aussi. J'écris encore : | > int i = 0 ; | > et non : | > std::vector< int > i( 1, 0 ) ; | > Je n'utilise la STL que quand il fait quelque chose dont j'ai | > besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou | > parce que c'est in. | > Le problème que je vois avec le XML, en fait, c'est qu'il essaie | > de fournir std::map sans vouloir même admettre l'existance | > possible de std::vector ni d'int. | > | | Là, je ne comprends pas.
C'est l'analogie qui est revenu en boomerang.
-- Gaby
Olivier Azeau <john@doe.com> writes:
| kanze@gabi-soft.fr wrote:
| > Gabriel Dos Reis wrote:
| > [...]
| >
| >>| ... mais parce que l'on va y trouver toute une panoplie de
| >>| services que l'on aurait bien du mal à réécrire soi même.
| >
| >>*si* ces services *conviennent* à l'application donnée. Ce qui
| >>est loin d'être acquis et c'est bien l'objet du débat (je
| >>parle toujours de XML et non de la STL).
| > Mais pourquoi pas parler de la STL aussi. J'écris encore :
| > int i = 0 ;
| > et non :
| > std::vector< int > i( 1, 0 ) ;
| > Je n'utilise la STL que quand il fait quelque chose dont j'ai
| > besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou
| > parce que c'est in.
| > Le problème que je vois avec le XML, en fait, c'est qu'il essaie
| > de fournir std::map sans vouloir même admettre l'existance
| > possible de std::vector ni d'int.
| >
|
| Là, je ne comprends pas.
| wrote: | > Gabriel Dos Reis wrote: | > [...] | > | >>| ... mais parce que l'on va y trouver toute une panoplie de | >>| services que l'on aurait bien du mal à réécrire soi même. | > | >>*si* ces services *conviennent* à l'application donnée. Ce qui | >>est loin d'être acquis et c'est bien l'objet du débat (je | >>parle toujours de XML et non de la STL). | > Mais pourquoi pas parler de la STL aussi. J'écris encore : | > int i = 0 ; | > et non : | > std::vector< int > i( 1, 0 ) ; | > Je n'utilise la STL que quand il fait quelque chose dont j'ai | > besoin. Je ne l'utilise pas juste pour dire que je l'utilise, ou | > parce que c'est in. | > Le problème que je vois avec le XML, en fait, c'est qu'il essaie | > de fournir std::map sans vouloir même admettre l'existance | > possible de std::vector ni d'int. | > | | Là, je ne comprends pas.
C'est l'analogie qui est revenu en boomerang.
-- Gaby
Gabriel Dos Reis
Olivier Azeau writes:
[...]
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine + | >> humain)? Si cela denote la semantique d'un complexe pour eviter | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > le type d'application, on peut utiliser (admettons que l'on veuille | > fixer un membre m à j) : | > m = #c(0 1) ;; pour reprendre la notation à CL | > ou : | > Member m ::= Complex 0 1 | > ou : | > <member name="m"> | > <complex real="0" imag="1"/> | > </member> | > | | Mais le principal avantage du XML c'est que si tu trouves que la 1ère | forme est plus lisible (question de goût), tu écris qqe chose comme ça | : | | <xsl:template match="//member"> | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | </xsl:template> | <xsl:template match="//complex"> | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours. La question n'est pas de faire avaler un format arbitraire à XML.
-- Gaby
Olivier Azeau <john@doe.com> writes:
[...]
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine +
| >> humain)? Si cela denote la semantique d'un complexe pour eviter
| >> d'appeler un chat un chat (i.e. prefixer par Complex),
| > Mais l'on recherche justement la manière d'appeler un chat. Selon
| > le type d'application, on peut utiliser (admettons que l'on veuille
| > fixer un membre m à j) :
| > m = #c(0 1) ;; pour reprendre la notation à CL
| > ou :
| > Member m ::= Complex 0 1
| > ou :
| > <member name="m">
| > <complex real="0" imag="1"/>
| > </member>
| >
|
| Mais le principal avantage du XML c'est que si tu trouves que la 1ère
| forme est plus lisible (question de goût), tu écris qqe chose comme ça
| :
|
| <xsl:template match="//member">
| <xsl:value-of select="@name"/> = <xsl:apply-templates/>
| </xsl:template>
| <xsl:template match="//complex">
| #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>)
| </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours.
La question n'est pas de faire avaler un format arbitraire à XML.
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine + | >> humain)? Si cela denote la semantique d'un complexe pour eviter | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > le type d'application, on peut utiliser (admettons que l'on veuille | > fixer un membre m à j) : | > m = #c(0 1) ;; pour reprendre la notation à CL | > ou : | > Member m ::= Complex 0 1 | > ou : | > <member name="m"> | > <complex real="0" imag="1"/> | > </member> | > | | Mais le principal avantage du XML c'est que si tu trouves que la 1ère | forme est plus lisible (question de goût), tu écris qqe chose comme ça | : | | <xsl:template match="//member"> | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | </xsl:template> | <xsl:template match="//complex"> | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours. La question n'est pas de faire avaler un format arbitraire à XML.
-- Gaby
Olivier Azeau
Gabriel Dos Reis wrote:
Olivier Azeau writes:
[...]
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine + | >> humain)? Si cela denote la semantique d'un complexe pour eviter | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > le type d'application, on peut utiliser (admettons que l'on veuille | > fixer un membre m à j) : | > m = #c(0 1) ;; pour reprendre la notation à CL | > ou : | > Member m ::= Complex 0 1 | > ou : | > <member name="m"> | > <complex real="0" imag="1"/> | > </member> | > | | Mais le principal avantage du XML c'est que si tu trouves que la 1ère | forme est plus lisible (question de goût), tu écris qqe chose comme ça | : | | <xsl:template match="//member"> | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | </xsl:template> | <xsl:template match="//complex"> | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours. La question n'est pas de faire avaler un format arbitraire à XML.
Il n'est pas question de faire avaler quoi que ce soit. Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
Je dis juste que si on critique la lisibilité de XML, il me semble honnête de préciser que s'il existe un format facile à rendre lisible en ASCII avec un effort minimum, c'est bien le XML. La réciproque est généralement fausse : transformer de l'ASCII en XML, c'est galère.
Gabriel Dos Reis wrote:
Olivier Azeau <john@doe.com> writes:
[...]
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine +
| >> humain)? Si cela denote la semantique d'un complexe pour eviter
| >> d'appeler un chat un chat (i.e. prefixer par Complex),
| > Mais l'on recherche justement la manière d'appeler un chat. Selon
| > le type d'application, on peut utiliser (admettons que l'on veuille
| > fixer un membre m à j) :
| > m = #c(0 1) ;; pour reprendre la notation à CL
| > ou :
| > Member m ::= Complex 0 1
| > ou :
| > <member name="m">
| > <complex real="0" imag="1"/>
| > </member>
| >
|
| Mais le principal avantage du XML c'est que si tu trouves que la 1ère
| forme est plus lisible (question de goût), tu écris qqe chose comme ça
| :
|
| <xsl:template match="//member">
| <xsl:value-of select="@name"/> = <xsl:apply-templates/>
| </xsl:template>
| <xsl:template match="//complex">
| #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>)
| </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours.
La question n'est pas de faire avaler un format arbitraire à XML.
Il n'est pas question de faire avaler quoi que ce soit.
Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
Je dis juste que si on critique la lisibilité de XML, il me semble
honnête de préciser que s'il existe un format facile à rendre lisible en
ASCII avec un effort minimum, c'est bien le XML.
La réciproque est généralement fausse : transformer de l'ASCII en XML,
c'est galère.
| >> A quoi sert "(;)", quelle information cela apporte-t-il (machine + | >> humain)? Si cela denote la semantique d'un complexe pour eviter | >> d'appeler un chat un chat (i.e. prefixer par Complex), | > Mais l'on recherche justement la manière d'appeler un chat. Selon | > le type d'application, on peut utiliser (admettons que l'on veuille | > fixer un membre m à j) : | > m = #c(0 1) ;; pour reprendre la notation à CL | > ou : | > Member m ::= Complex 0 1 | > ou : | > <member name="m"> | > <complex real="0" imag="1"/> | > </member> | > | | Mais le principal avantage du XML c'est que si tu trouves que la 1ère | forme est plus lisible (question de goût), tu écris qqe chose comme ça | : | | <xsl:template match="//member"> | <xsl:value-of select="@name"/> = <xsl:apply-templates/> | </xsl:template> | <xsl:template match="//complex"> | #c(<xsl:value-of select="@real"/> <xsl:value-of select="@imag"/>) | </xsl:template>
C'était lisible, donc on met plus de bruit, c'est ça ?
| Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
je crois que ton newsreader te joue des tours sur le débat en cours. La question n'est pas de faire avaler un format arbitraire à XML.
Il n'est pas question de faire avaler quoi que ce soit. Qui a parlé de faire avaler un format arbitraire à XML ? pas moi en tt cas.
Je dis juste que si on critique la lisibilité de XML, il me semble honnête de préciser que s'il existe un format facile à rendre lisible en ASCII avec un effort minimum, c'est bien le XML. La réciproque est généralement fausse : transformer de l'ASCII en XML, c'est galère.
drkm
Olivier Azeau writes:
Mais le principal avantage du XML c'est que si tu trouves que la 1ère forme est plus lisible (question de goût), tu écris qqe chose comme ça :
Et tes données ne s'afficheront pas en XML mais avec ta notation préférée. Sur un exemple aussi simple, on va me rétorquer que avec une ligne de AWK je peux tout aussi bien faire l'inverse mais dès que l'on commence à imbriquer des données, le XML gagne facilement.
Bof. XSLT est puissant, mais n'est pas si simple. Il suffit de voir les articles à ce sujet sur f.c.t.xml. D'ailleurs, ton exemple ne fonctionne pas. Un meilleur serait :
Et tes données ne s'afficheront pas en XML mais avec ta notation préférée.
Sur un exemple aussi simple, on va me rétorquer que avec une ligne de
AWK je peux tout aussi bien faire l'inverse mais dès que l'on commence à
imbriquer des données, le XML gagne facilement.
Bof. XSLT est puissant, mais n'est pas si simple. Il suffit de
voir les articles à ce sujet sur f.c.t.xml. D'ailleurs, ton exemple
ne fonctionne pas. Un meilleur serait :
Et tes données ne s'afficheront pas en XML mais avec ta notation préférée. Sur un exemple aussi simple, on va me rétorquer que avec une ligne de AWK je peux tout aussi bien faire l'inverse mais dès que l'on commence à imbriquer des données, le XML gagne facilement.
Bof. XSLT est puissant, mais n'est pas si simple. Il suffit de voir les articles à ce sujet sur f.c.t.xml. D'ailleurs, ton exemple ne fonctionne pas. Un meilleur serait :
Et comment tu fais pour : struct Y{}; struct X { Y* y; };
Y y; X x1, x2; x1.y = x2.y = &y;
Et pour struct B{}; struct D1:B{}; struct D2:B{};
struct X{vector<B*> data;};
Maintenant, comment faire la même chose en ASCII ? Et surtout coder en C++ le parser associé ?
Par exemple avec boost::serialisation, ou toute autre bibliothèque de sérialisation bien faite, çe se fait en une ligne par classe.
Les exemples ci dessus se codent ainsi (lecture et écriture d'un coup) : Cas 1 : Ajouter dans X (on peut aussi mettre dehors...) : template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & a; }
Cas 2 : Ajouter dans X : template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & b; }
Cas 3: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & y; // on suppose la sérialisation de y faite }
Cas 4: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & data; // on suppose la sérialisation de B, D1 et D2 faite }
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce qui compte pour la facilité à coder, ce n'est pas le format de sortie, mais uniquement la qualité de la bibliothèque de sérialisation.
-- Loïc
Olivier Azeau wrote:
Quoi de plus simple pour sérialiser:
struct X
{
int a;
};
que : <X a='13'/> ?
X {a}
Et si on veut du complexe, ce n'est pas bcp plus cher. Par exemple :
struct X
{
std::vector<std::vector<int>> b;
};
Et comment tu fais pour :
struct Y{};
struct X
{
Y* y;
};
Y y;
X x1, x2;
x1.y = x2.y = &y;
Et pour
struct B{};
struct D1:B{};
struct D2:B{};
struct X{vector<B*> data;};
Maintenant, comment faire la même chose en ASCII ? Et surtout coder en
C++ le parser associé ?
Par exemple avec boost::serialisation, ou toute autre bibliothèque de
sérialisation bien faite, çe se fait en une ligne par classe.
Les exemples ci dessus se codent ainsi (lecture et écriture d'un coup) :
Cas 1 :
Ajouter dans X (on peut aussi mettre dehors...) :
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & a;
}
Cas 2 :
Ajouter dans X :
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & b;
}
Cas 3:
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & y; // on suppose la sérialisation de y faite
}
Cas 4:
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
ar & data; // on suppose la sérialisation de B, D1 et D2 faite
}
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique
plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce
qui compte pour la facilité à coder, ce n'est pas le format de sortie,
mais uniquement la qualité de la bibliothèque de sérialisation.
Et comment tu fais pour : struct Y{}; struct X { Y* y; };
Y y; X x1, x2; x1.y = x2.y = &y;
Et pour struct B{}; struct D1:B{}; struct D2:B{};
struct X{vector<B*> data;};
Maintenant, comment faire la même chose en ASCII ? Et surtout coder en C++ le parser associé ?
Par exemple avec boost::serialisation, ou toute autre bibliothèque de sérialisation bien faite, çe se fait en une ligne par classe.
Les exemples ci dessus se codent ainsi (lecture et écriture d'un coup) : Cas 1 : Ajouter dans X (on peut aussi mettre dehors...) : template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & a; }
Cas 2 : Ajouter dans X : template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & b; }
Cas 3: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & y; // on suppose la sérialisation de y faite }
Cas 4: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & data; // on suppose la sérialisation de B, D1 et D2 faite }
Et pour info, parmi les formats gérés, XML (enrichi par une sémantique plus riche pour gérer les pointeurs) existe. Tout ça pour dire que ce qui compte pour la facilité à coder, ce n'est pas le format de sortie, mais uniquement la qualité de la bibliothèque de sérialisation.
