« basé sur gccxml ». Ok, je comprends mieux. Merci.
Mais il s'agit ici d'introspection. Si je comprend bien ton « compilation », il y a une phase de compilation (style gccxml) qui génère une base de description de classes, utilisée pour l'introspection. À partir de laquelle on peut construire des outils de sérialisation.
« basé sur gccxml ». Ok, je comprends mieux. Merci.
Mais il s'agit ici d'introspection. Si je comprend bien ton
« compilation », il y a une phase de compilation (style gccxml) qui
génère une base de description de classes, utilisée pour
l'introspection. À partir de laquelle on peut construire des outils
de sérialisation.
« basé sur gccxml ». Ok, je comprends mieux. Merci.
Mais il s'agit ici d'introspection. Si je comprend bien ton « compilation », il y a une phase de compilation (style gccxml) qui génère une base de description de classes, utilisée pour l'introspection. À partir de laquelle on peut construire des outils de sérialisation.
--drkm
kanze
Loïc Joly wrote:
Arnaud Debaene wrote:
wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote:
Arnaud Debaene wrote:
noone@nowhere.com wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation
des objets... :-(
En fait, je dirais que le manque est plus du côté de
l'introspection, qui permettrait de faire une sérialisation
"par défaut" automatique des objets, mais d'autres choses
aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place
dans un langage, étant donné la variété dans les besoins. C'est
même assez fréquent de vouloir supporter plusieurs formats de
sérialisation dans une seule application (pour la persistence,
pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une
sérialisation avec le format voulu.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
writes:
Loïc Joly wrote:
Arnaud Debaene wrote:
wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants. Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
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
kanze@gabi-soft.fr writes:
Loïc Joly wrote:
Arnaud Debaene wrote:
noone@nowhere.com wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation
des objets... :-(
En fait, je dirais que le manque est plus du côté de
l'introspection, qui permettrait de faire une sérialisation
"par défaut" automatique des objets, mais d'autres choses
aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place
dans un langage, étant donné la variété dans les besoins. C'est
même assez fréquent de vouloir supporter plusieurs formats de
sérialisation dans une seule application (pour la persistence,
pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation
avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles la
persistance ou la serialisation sont pertinentes mais qui ont des
membres ne devant pas etre serialises ou rendus persistants. Comment
de l'introspection seule peut-elle rendre la chose automatique sans
avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java
si j'ai bonne memoire)?
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
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants. Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
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
Michael
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et
quelles sont ses utilités?
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
noone
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un objet. Désérialiser c'est l'opération inverse. En C# (ou Java) on peut facilement sérialiser en XML. L'intérêt c'est de faciliter le stockage d'information et la restitution de cette même information.
Exemple tu prends un complexe 1+2i Ta classe Complexe contient un attribut partie_reelle et un attribut partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte : 1;2;
En serialisant en XML on a <Complexe> <partie_reelle>1</partie_reelle> <partie_imaginaire>2</partie_imaginaire> </Complexe>
L'intérêt de sérialiser en XML c'est que XML est portable (mais comme on l'a dit on peut sérialiser vers autre chose) En +, on peut ensuite générer plein de chose via des transformations XSLT. Par exemple générer depuis le fichier XML plus haut un fichier PDF ou PS qui représente 2 axes et le point en question, etc...
En espérant avoir été assez clair car je ne suis pas spécialiste.
Cordialement
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et
quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un objet.
Désérialiser c'est l'opération inverse.
En C# (ou Java) on peut facilement sérialiser en XML.
L'intérêt c'est de faciliter le stockage d'information et la restitution
de cette même information.
Exemple tu prends un complexe 1+2i
Ta classe Complexe contient un attribut partie_reelle et un attribut
partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte :
1;2;
En serialisant en XML on a
<Complexe>
<partie_reelle>1</partie_reelle>
<partie_imaginaire>2</partie_imaginaire>
</Complexe>
L'intérêt de sérialiser en XML c'est que XML est portable (mais comme on
l'a dit on peut sérialiser vers autre chose)
En +, on peut ensuite générer plein de chose via des transformations XSLT.
Par exemple générer depuis le fichier XML plus haut un fichier PDF ou PS
qui représente 2 axes et le point en question, etc...
En espérant avoir été assez clair car je ne suis pas spécialiste.
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un objet. Désérialiser c'est l'opération inverse. En C# (ou Java) on peut facilement sérialiser en XML. L'intérêt c'est de faciliter le stockage d'information et la restitution de cette même information.
Exemple tu prends un complexe 1+2i Ta classe Complexe contient un attribut partie_reelle et un attribut partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte : 1;2;
En serialisant en XML on a <Complexe> <partie_reelle>1</partie_reelle> <partie_imaginaire>2</partie_imaginaire> </Complexe>
L'intérêt de sérialiser en XML c'est que XML est portable (mais comme on l'a dit on peut sérialiser vers autre chose) En +, on peut ensuite générer plein de chose via des transformations XSLT. Par exemple générer depuis le fichier XML plus haut un fichier PDF ou PS qui représente 2 axes et le point en question, etc...
En espérant avoir été assez clair car je ne suis pas spécialiste.
Cordialement
Loïc Joly
Jean-Marc Bourguet wrote:
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants. Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
Je ne sais pas pour Java, mais c'est le genre d'option retenue dans les langages .NET. Avec de mémoire la possibilité d'aller plus loin qu'un simple on/off, mais de donner des infos sur comment sérialiser.
Et je n'aime pas trop. Déjà on peut imaginer vouloir sérialiser différemment une seule classe, mais surtout, je trouve que ça rajoute dans la définition de la classe des informations qui n'ont rien à y faire, et encombrent donc.
J'aurais plus tendance à opter pour quelquechose genre boost::serialization, mais avec une valeur par défaut issue de l'introspection.
-- Loïc
Jean-Marc Bourguet wrote:
J'ai une proportion non negligeable de classes pour lesquelles la
persistance ou la serialisation sont pertinentes mais qui ont des
membres ne devant pas etre serialises ou rendus persistants. Comment
de l'introspection seule peut-elle rendre la chose automatique sans
avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java
si j'ai bonne memoire)?
Je ne sais pas pour Java, mais c'est le genre d'option retenue dans les
langages .NET. Avec de mémoire la possibilité d'aller plus loin qu'un
simple on/off, mais de donner des infos sur comment sérialiser.
Et je n'aime pas trop. Déjà on peut imaginer vouloir sérialiser
différemment une seule classe, mais surtout, je trouve que ça rajoute
dans la définition de la classe des informations qui n'ont rien à y
faire, et encombrent donc.
J'aurais plus tendance à opter pour quelquechose genre
boost::serialization, mais avec une valeur par défaut issue de
l'introspection.
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants. Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
Je ne sais pas pour Java, mais c'est le genre d'option retenue dans les langages .NET. Avec de mémoire la possibilité d'aller plus loin qu'un simple on/off, mais de donner des infos sur comment sérialiser.
Et je n'aime pas trop. Déjà on peut imaginer vouloir sérialiser différemment une seule classe, mais surtout, je trouve que ça rajoute dans la définition de la classe des informations qui n'ont rien à y faire, et encombrent donc.
J'aurais plus tendance à opter pour quelquechose genre boost::serialization, mais avec une valeur par défaut issue de l'introspection.
-- Loïc
James Kanze
Jean-Marc Bourguet wrote:
writes:
Loïc Joly wrote:
Arnaud Debaene wrote:
wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants.
C'est souvent le cas.
Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
La solution de Java n'aide pas forcement, parce que typiquement, on sérialise pour plusieurs raisons, souvent dans le même programme, et souvent avec d'autres critère en ce qui concerne les éléments qu'il faut inclure, et ce qu'il ne faut pas.
Mais même dans ces cas, l'introspection aide. Il permet au moins à définir la sérialisation (ou les sérialisations) en dehors de la classe (au moyen des listes d'exclusion ou d'inclusion).
Aussi, il faut dire que le problème est moins aigu qu'en Java. Souvent, une règle simple, du genre à ne pas suivre les pointeurs, suffira. (Tandis qu'en Java, ne pas suivre les pointeurs, ça ne donnerait pas grand chose.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
kanze@gabi-soft.fr writes:
Loïc Joly wrote:
Arnaud Debaene wrote:
noone@nowhere.com wrote:
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation
des objets... :-(
En fait, je dirais que le manque est plus du côté de
l'introspection, qui permettrait de faire une sérialisation
"par défaut" automatique des objets, mais d'autres choses
aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place
dans un langage, étant donné la variété dans les besoins.
C'est même assez fréquent de vouloir supporter plusieurs
formats de sérialisation dans une seule application (pour la
persistence, pour la communication avec d'autres applications,
etc.).
Avec l'introspection, c'est assez facile à écrire une
sérialisation avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles
la persistance ou la serialisation sont pertinentes mais qui
ont des membres ne devant pas etre serialises ou rendus
persistants.
C'est souvent le cas.
Comment de l'introspection seule peut-elle rendre
la chose automatique sans avoir un attribut supplementaire
pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
La solution de Java n'aide pas forcement, parce que typiquement,
on sérialise pour plusieurs raisons, souvent dans le même
programme, et souvent avec d'autres critère en ce qui concerne
les éléments qu'il faut inclure, et ce qu'il ne faut pas.
Mais même dans ces cas, l'introspection aide. Il permet au moins
à définir la sérialisation (ou les sérialisations) en dehors de
la classe (au moyen des listes d'exclusion ou d'inclusion).
Aussi, il faut dire que le problème est moins aigu qu'en Java.
Souvent, une règle simple, du genre à ne pas suivre les
pointeurs, suffira. (Tandis qu'en Java, ne pas suivre les
pointeurs, ça ne donnerait pas grand chose.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
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++.
C'est l'un des gros manques du C++ AMHA : la sérialisation des objets... :-(
En fait, je dirais que le manque est plus du côté de l'introspection, qui permettrait de faire une sérialisation "par défaut" automatique des objets, mais d'autres choses aussi.
Tout à fait. La sérialisation en soi n'a pas vraiment sa place dans un langage, étant donné la variété dans les besoins. C'est même assez fréquent de vouloir supporter plusieurs formats de sérialisation dans une seule application (pour la persistence, pour la communication avec d'autres applications, etc.).
Avec l'introspection, c'est assez facile à écrire une sérialisation avec le format voulu.
J'ai une proportion non negligeable de classes pour lesquelles la persistance ou la serialisation sont pertinentes mais qui ont des membres ne devant pas etre serialises ou rendus persistants.
C'est souvent le cas.
Comment de l'introspection seule peut-elle rendre la chose automatique sans avoir un attribut supplementaire pour indiquer ce fait (ce qu'a Java si j'ai bonne memoire)?
La solution de Java n'aide pas forcement, parce que typiquement, on sérialise pour plusieurs raisons, souvent dans le même programme, et souvent avec d'autres critère en ce qui concerne les éléments qu'il faut inclure, et ce qu'il ne faut pas.
Mais même dans ces cas, l'introspection aide. Il permet au moins à définir la sérialisation (ou les sérialisations) en dehors de la classe (au moyen des listes d'exclusion ou d'inclusion).
Aussi, il faut dire que le problème est moins aigu qu'en Java. Souvent, une règle simple, du genre à ne pas suivre les pointeurs, suffira. (Tandis qu'en Java, ne pas suivre les pointeurs, ça ne donnerait pas grand chose.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
wrote:
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un objet. Désérialiser c'est l'opération inverse.
Pas forcement. Sérialiser, c'est de mettre l'objet à plat, en tant qu'une suite d'octets ou de bits, sans autre structure explicite. Il peut servir pour le stockage sur disque, mais aussi pour la transmission des données entre deux processus ou deux machines.
La désérialisation en est, effectivement, l'inverse.
En C# (ou Java) on peut facilement sérialiser en XML. L'intérêt c'est de faciliter le stockage d'information et la restitution de cette même information.
Avoir besoin d'un parseur XML, je n'appelle pas ça faciliter. Et c'est difficile à concevoir des situations où XML serait le format de choix.
Exemple tu prends un complexe 1+2i Ta classe Complexe contient un attribut partie_reelle et un attribut partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte : 1;2;
En serialisant en XML on a <Complexe> <partie_reelle>1</partie_reelle> <partie_imaginaire>2</partie_imaginaire> </Complexe>
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.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
noone@nowhere.com wrote:
J'ai peur de paraître ridicule, mais en quoi consiste la
sérialisation et quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un
objet. Désérialiser c'est l'opération inverse.
Pas forcement. Sérialiser, c'est de mettre l'objet à plat, en
tant qu'une suite d'octets ou de bits, sans autre structure
explicite. Il peut servir pour le stockage sur disque, mais
aussi pour la transmission des données entre deux processus ou
deux machines.
La désérialisation en est, effectivement, l'inverse.
En C# (ou Java) on peut facilement sérialiser en XML.
L'intérêt c'est de faciliter le stockage d'information et la
restitution de cette même information.
Avoir besoin d'un parseur XML, je n'appelle pas ça faciliter. Et
c'est difficile à concevoir des situations où XML serait le
format de choix.
Exemple tu prends un complexe 1+2i
Ta classe Complexe contient un attribut partie_reelle et un
attribut partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte :
1;2;
En serialisant en XML on a
<Complexe>
<partie_reelle>1</partie_reelle>
<partie_imaginaire>2</partie_imaginaire>
</Complexe>
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.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
J'ai peur de paraître ridicule, mais en quoi consiste la sérialisation et quelles sont ses utilités?
Sérialiser consiste à stocker par exemple les attributs d'un objet. Désérialiser c'est l'opération inverse.
Pas forcement. Sérialiser, c'est de mettre l'objet à plat, en tant qu'une suite d'octets ou de bits, sans autre structure explicite. Il peut servir pour le stockage sur disque, mais aussi pour la transmission des données entre deux processus ou deux machines.
La désérialisation en est, effectivement, l'inverse.
En C# (ou Java) on peut facilement sérialiser en XML. L'intérêt c'est de faciliter le stockage d'information et la restitution de cette même information.
Avoir besoin d'un parseur XML, je n'appelle pas ça faciliter. Et c'est difficile à concevoir des situations où XML serait le format de choix.
Exemple tu prends un complexe 1+2i Ta classe Complexe contient un attribut partie_reelle et un attribut partie_imaginaire.
Tu pourrais stocker ça dans un fichier texte : 1;2;
En serialisant en XML on a <Complexe> <partie_reelle>1</partie_reelle> <partie_imaginaire>2</partie_imaginaire> </Complexe>
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.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Arnaud Debaene
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). C'est ce qui est utilisé lourdement par les Web Services.
J'ai aussi vu des cas où chaque programme avait sa propre définition d'un type (définitions différentes dans les 2 langages, avec pas les mêmes opérations, certaines données membres différentes, mais certaines données membres communes aux 2). Les 2 programmes s'échangent ces objets en ne sérialisant en XML que les données que l'on retrouve dans les 2 versions, et chacune en validant le XML avec son propre DTD (qui est un mapping de sa structure objet).
Dans ce cas, les données membres qui diffèrent dans les 2 programmes sont initialisées à leur valeur par défaut lors de la déserialsiation. On obtient ainsi un espece de "typage souple" qui peut être bien pratique pour faire fonctionner des composants hétérogènes ensembles.
Arnaud
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). C'est ce qui est utilisé lourdement par les Web
Services.
J'ai aussi vu des cas où chaque programme avait sa propre définition d'un
type (définitions différentes dans les 2 langages, avec pas les mêmes
opérations, certaines données membres différentes, mais certaines données
membres communes aux 2). Les 2 programmes s'échangent ces objets en ne
sérialisant en XML que les données que l'on retrouve dans les 2 versions, et
chacune en validant le XML avec son propre DTD (qui est un mapping de sa
structure objet).
Dans ce cas, les données membres qui diffèrent dans les 2 programmes sont
initialisées à leur valeur par défaut lors de la déserialsiation. On obtient
ainsi un espece de "typage souple" qui peut être bien pratique pour faire
fonctionner des composants hétérogènes ensembles.
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). C'est ce qui est utilisé lourdement par les Web Services.
J'ai aussi vu des cas où chaque programme avait sa propre définition d'un type (définitions différentes dans les 2 langages, avec pas les mêmes opérations, certaines données membres différentes, mais certaines données membres communes aux 2). Les 2 programmes s'échangent ces objets en ne sérialisant en XML que les données que l'on retrouve dans les 2 versions, et chacune en validant le XML avec son propre DTD (qui est un mapping de sa structure objet).
Dans ce cas, les données membres qui diffèrent dans les 2 programmes sont initialisées à leur valeur par défaut lors de la déserialsiation. On obtient ainsi un espece de "typage souple" qui peut être bien pratique pour faire fonctionner des composants hétérogènes ensembles.
