Discussion :

[Gm7468]

Bonjour,

Dans un projet de développement C++, j'utilise et manipule des points. Ces derniers ont de nombreux attributs (id, x, y et z notamment). Tous les points utiles au fonctionnement sont stockés dans un fichier XML du type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<Points>
     <Point>
          <id>1</id>
          <x>1000</x>
          <y>5000</y>
          <z>100</z>
      </Point>
      ...
</Points>

Les manipulations sur ces points sont plus ou moins poussées, avec des calculs divers, des approximations de plans, calculs de distances point-plan, etc...

Quelle est la meilleure façon de procéder quant à l'architecture du code?

A priori, je pense à 2 solutions totalement différentes:
1- Créer une classe Point (et une classe Plan...), et dès le début du programme, lire le XML et instancier directement chaque point contenu dans le fichier. Les calculs effectués le seront directement sur les objets, avec les méthodes contenues dans chaque classe (plus une classe "Calculs" pour les autres opérations qui ne rentreraient pas dans les classes).
2- Ne pas créer de classe, uniquement des fichiers .cpp et .h pour les calculs. Lors de l'exécution du programme, on chargerait une fois le fichier XML dans une variable, puis on appellerait les différentes fonctions en passant en variable les nœuds xml nécessaires. On n'aurait donc pas besoin de créer d'objet, tout se ferait à partir de l'xml.

Pour résumer:
- fonctionnement 1:
On charge le XML -> on crée tous les objets points nécessaires.
On manipule les objets directement à partir des méthodes des classes.
exemple:
constructeur: Point i(id,x,y,z);
double dist = CalculDistancePointPlan(Point i, Plan p);

- fonctionnement 2:
On charge le XML -> on garde le tout dans une variable pour utilisation ultérieure.
On exécute le programme, et lors du besoin de paramètres, on va les chercher dans le flux xml avec une requête XQuery.
exemple:
double x = résultat de la requête (donne moi le x du point courant)
idem pour y et z
idem pour le plan
double dist = CalculDistancePointPlan(x,y,z, a,b,c,d);

A mon humble avis de débutant programmeur, la solution 1- me parait plus "propre", plus ordonnée, et conceptuellement plus logique. Cependant, cette solution perd totalement tous les avantages liés à l'utilisation du XML, en le lisant pas à pas comme on le ferait pour un simple fichier .ini. Alors que la seconde solution exploite les possibilités à fond en utilisant XQuery à chaque appel.

Quel est votre avis sur la question?

[cob59]

XQuery est intéressant quand on doit chercher une certaine info tout au fond de l'arborescence du XML. Si j'ai bien compris, c'est tout le XML qui t'intéresse, donc il vaut mieux le rapatrier entièrement dans une classe/structure idoine comme décrit en #1. Je ne sais pas si c'est le pattern le plus judicieux, mais d'habitude je procède comme ça :

Tes modèles de base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
struct Point { int x,y,z,id; }
struct PointCloud { std::vector<Point> points };

Classes chargées des opération d'écriture/lecture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
struct PointCloudXmlReader {
  PointXmlReader(PointCloud& pc) : pc(pc) {}
  void readFrom(const std::string& filename) { ... }
private:
  PointCloud& pc;
};

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
struct PointCloudXmlWriter {
  PointCloudXmlWriter(const PointCloud& pc) : pc(pc) {}
  void writeTo(const std::string& filename) const { ... }
private:
  const PointCloud& pc;
};

Exploitation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
PointCloud cloud;
 
// Lecture du XML
{
  PointCloudXmlReader reader(cloud);
  reader.readFrom("fichier.xml");
}
 
assert ( cloud.points.size() > 0 );
 
// Modifications
...
 
// Ecriture du XML
{
  PointCloudXmlWriter writer(cloud);
  writer.writeTo("fichier.xml");
}

Ca permet de rendre tes données indépendantes du format de sérialisation (ici le XML) et de la lib utilisée pour sérialiser (peut-être pugixml dans ton cas). Pour bien faire, mon reader devrait hériter d'une classe abstraite PointCloudReader qui se sous-classerait selon différents format (XML, INI, binaire, ...). Idem pour le writer.

[Gm7468]

D'accord, c'est effectivement ce que j'avais pré-senti, à savoir que XQuery est très puissant ponctuellement, mais pas pour la lecture d'un document complet.

Si j'ai bien compris, ce que tu proposes, c'est de faire de la sérialisation/dé-sérialisation? J'avais déjà trouvé quelques infos sur le sujet, mais en tant que grand débutant en programmation et en C++, cela m'avait semblé relativement complexe à mettre en place.

J'utilise Qt (ou BOOST si besoin ou plus pratique...), et les modules XML/XMLPattern offrent a priori de bonnes possibilités pour parser/sérialser du XML, mais encore faut-il réussir à les mettre en place.

Quelle est la meilleure méthode?
Utiliser DOM, SAX ou la sérialisation?

[Bousk]

Bonjour,

perso j'aurais également fait comme ça.
D'abord parce que c'est plus simple à réaliser je trouve et à suivre en debug, tu as tes points et tu peux vérifier que leurs coordonnées sont correctes, les modifier etc.
Pour le xml j'utilise tinyXml, mais n'importe quelle classe de lecture xml devrait faire l'affaire.

[cob59]

Si tu travailles sous Qt, ce que j'ai fourni existe probablement déjà pour DOM et SAX. http://www.digitalfanatics.org/proje...chapter09.html

Mais la sérialisation en elle-même n'a rien de compliqué. Dans ton cas il s'agit seulement de sauvegarder ta structure de données PointCloud selon l'arborescence XML que tu auras décidé, et inversement.

[Gm7468]

J'ai peut être un problème de compréhension/conception:
Est-ce que la sérialisation/désérialisation est une méthode de lecture/écriture au même titre que DOM ou SAX?
Ou est-ce qu'elle utilise DOM et/ou SAX pour lire/écrire?

En quelques sorte, est-ce que la sérialisation est le concept, et SAX le moyen?

[cob59]

La sérialisation n'est qu'un terme générique pour décrire la conversion de données dans un format qui permettra leur conservation (ex: fichier XML) ou leur envoi via le réseau. Et DOM/SAX ne sont effectivement qu'un moyen pour y parvenir.

[Gm7468]

D'accord donc déjà par rapport à ca j'avais un problème de compréhension. Je pensais que c'était un moyen parmi les autres. Lumière est faite sur ce point.

Classes chargées des opération d'écriture/lecture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
struct PointCloudXmlReader {
  PointXmlReader(PointCloud& pc) : pc(pc) {}
  void readFrom(const std::string& filename) { ... }
private:
  PointCloud& pc;
};

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
struct PointCloudXmlWriter {
  PointCloudXmlWriter(const PointCloud& pc) : pc(pc) {}
  void writeTo(const std::string& filename) const { ... }
private:
  const PointCloud& pc;
};

Donc si je comprends bien cette fois, les classes Reader et Writer sont là pour faire le travail de sérialisation/désérialisation, et ces classes dérivent de PointCloud (ou carrément des méthodes de PointCloud...). La méthode readFrom() remplit donc le PointCloud pc en lisant le fichier xml. Et c'est dans cette méthode qu'on utilise DOM ou SAX pour lire les différents noeuds et affecter leurs valeurs aux attributs des points eux-mêmes insérés dans la liste du PointCloud.

C'est exact?

[Bousk]

Les reader et writer ne dérivent pas de PointCloud.
Elles l'utilisent (PointCloud est paramètre du constructeur) et servent à faire la liaison entre le PointCloud et le fichier à lire et où écrire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
class PointCloud;
class PointCloudReader {...}; // interface reader
class PointCloudWriter {...}; // interface writer
class PointCloudXMLReader : public PointCloudReader {...}: // reader XML
class PointCloudINIReader : public PointCloudReader {...}; // reader INI
...

[Gm7468]

D'accord d'accord ce sont des classes à coté.

Une question supplémentaire cependant pour éclairer ma toute première interrogation.
A vrai dire, je n'ai pas besoin de tout le contenu du fichier XML en permanence. Mes points ne décrivent en effet pas un nuage de points (PointCloud), mais réellement des points séparés, traités séparément. A un instant t du programme, j'ai donc besoin du point i et de ses attributs, mais pas forcément des autres points.
Est-ce que ca change quelque chose dans le choix entre XQuery et DOM/SAX?
Sachant qu'effectivement, de toute façon tous les points du XML seront traités, mais pas simultanément...

[cob59]

Donc si je comprends bien cette fois, les classes Reader et Writer sont là pour faire le travail de sérialisation/désérialisation, et ces classes dérivent de PointCloud (ou carrément des méthodes de PointCloud...). La méthode readFrom() remplit donc le PointCloud pc en lisant le fichier xml. Et c'est dans cette méthode qu'on utilise DOM ou SAX pour lire les différents noeuds et affecter leurs valeurs aux attributs des points eux-mêmes insérés dans la liste du PointCloud.

C'est exact?

C'est bien ça.

A ceci près que que les reader/writer ne dérivent pas de PointCloud, mais agrègent un objet PointCloud. Dans le cas du writer l'agrégation est constante puisque l'objet ne sera normalement pas modifié. Quand j'ai parlé d'héritage, je pensais à quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
// Classe mère abstraite
struct PointCloudReader {
  virtual void readFrom(std::istream& is) = 0;
};
 
// Classes filles, adaptées à différentes sources
struct PointCloudXmlReader : PointCloudReader {
  void readFrom(const std::string& filename) { readFrom(std::ifstream(filename)); }
  virtual void readFrom(std::istream& is) { ... }
};
 
struct PointCloudIniFileReader : PointCloudReader { ... };
struct PointCloudRawFileReader : PointCloudReader { ... };
struct PointCloudDatabaseReader : PointCloudReader { ... };

-- edit : précédé par Bousk --

A vrai dire, je n'ai pas besoin de tout le contenu du fichier XML en permanence. Mes points ne décrivent en effet pas un nuage de points (PointCloud), mais réellement des points séparés, traités séparément. A un instant t du programme, j'ai donc besoin du point i et de ses attributs, mais pas forcément des autres points.
Est-ce que ca change quelque chose dans le choix entre XQuery et DOM/SAX?
Sachant qu'effectivement, de toute façon tous les points du XML seront traités, mais pas simultanément...

Pour des questions de performances, tes accès au XML doivent être les moins nombreux possible... Si ton XML est d'une taille raisonnable, mieux vaut le stocker en RAM une bonne fois pour toute. Dans le cas contraire, utilise plutôt une API SAX ; et fait en sorte que tes modèles ne représentent qu'une "portion" de ton arborescence XML.

[Gm7468]

Pour des questions de performances, tes accès au XML doivent être les moins nombreux possible...

Qu'entends-tu par "accès au XML"?
Si c'est l'accès au fichier.XML, c'est d'accord, ouvrir et fermer sans arrêt le fichier est inadéquat.
Par contre, si on charge le fichier XML dans un flux XML (on lit le fichier et on place le tout dans une variable), est-ce que ca pose problème d'y accéder?
Puisque finalement on accède à une variable comme une autre, mais qui contient le fichier xml.

Ma question correspond à la seconde version des accès: le contenu du xml stocké dans une variable. Vaut-il mieux garder cette variable et y accéder avec XQuery ou ne l'utiliser que pour créer les objets avec SAX puis la supprimer?

Dans mon application, j'envisage une bonne cinquantaine de points, ayant chacun une vingtaine d'attributs. Ca fait un fichier xml potentiellement assez lourd, et c'est pour cette raison que la question de la performance m'intéresse.

[cob59]

Ma question correspond à la seconde version des accès: le contenu du xml stocké dans une variable. Vaut-il mieux garder cette variable et y accéder avec XQuery ou ne l'utiliser que pour créer les objets avec SAX puis la supprimer?

Pour autant que je sache, en utilisant une API DOM cette "variable" existera quoiqu'il arrive. J'ai tendance à penser que les requêtes XQuery devraient rester des détails d'implémentation, et non pas des "pseudo-accesseurs", d'une part pour limiter l'interdépendance de tes classes, d'autre part pour mettre "en cache" le résultat d'une requête XQuery et donc économiser du temps de calcul lors d'éventuels futurs accès.

Dans mon application, j'envisage une bonne cinquantaine de points, ayant chacun une vingtaine d'attributs. Ca fait un fichier xml potentiellement assez lourd, et c'est pour cette raison que la question de la performance m'intéresse.

A partir de 10000 points tu pourrais peut-être te poser des questions. Là, ça reste un XML très léger.

[Gm7468]

Cette "variable" existera effectivement forcément, même en utilisant DOM. Cependant, avec DOM elle sera ponctuelle, une fois les objets créés à partir d'elle, elle sera supprimée. Par contre, avec XQuery, cette "variable" resterait utile tout au long du programme et des objets ne seraient pas nécessaires.

J'ai peut-être mal posé mes questions, étant débutant dans pratiquement tous les sujets abordés ici:

J'ai un fichier XML qui contient les infos de mes points. Pour les utiliser dans le programme, j'envisage 2 solutions:
1- Créer des objets Points (à partir du xml, puis refermer le xml)
2- Garder la variable issue du xml (pour "stocker" l'ensemble des points)

Et suivant le choix effectué, pour accéder aux infos des points, j'ai:
1- soit des accesseurs "normaux" dans le cas d'objets points
2- soit utiliser XQuery comme "pseudo-accesseur" des infos contenues dans la variable xml

D'après nos discussions, la solution 2- passer par XQuery en lecture sur la variable xml est à écarter.
Par conséquent, il faut que je crée des objets Points, dont les attributs seront donnés par des accesseurs de classe. Cependant, pour créer ces objets, je peux à nouveau utiliser soit DOM, soit SAX, soit XQuery...

Jusque là c'est cohérent?

[koala01]

Salut,

Il faut te dire que, quel que soit le système (sax, dom ou autre) utilisé, la manipulation et la conversion de chaines de caractères est particulièrement couteuse.

Ce problème peut rapidement devenir sérieux si, pour une raison ou une autre, tu en viens à te retrouver face à l'obligation de rechercher / comparer / convertir les informations dont tu disposes pour un point donné plusieurs fois, parce que le point que tu traites en particulier a besoin d'un point déjà traité comme référence.

De plus, pour utile qu'il soit, il faut malgré tout reconnaitre que le ratio entre la taille des données réellement utiles et la taille d'un fichier XML n'est pas des plus avantageuse, à cause de la présence des balises et des (potentiellement) nombreuses paires clé = valeur.

Je crois, sincèrement, que sauf cas particulier, il te sera largement préférable d'envisager de gérer tes points sous la forme de structures personnalisées, au risque de perdre l'avantage du XML, mais de manière à n'avoir qu'une seule fois la conversion à faire

Il faut bien te dire que XML n'est jamais qu'un format d'échange et que, s'il est très bon dans ce role, il ne doit malgré tout pas être considéré pour plus que cela

Sers toi si tu veux de dom ou de sax pour vérifier la cohérence des données que tu trouves dans ton XML, car c'est fait pour (entre autres choses)...

Mais, personnellement, je te conseillerais vraiment de passer à "un autre format" de représentation des données dés que possible une fois que tu as la certitude que les données contenues dans le XML sont au bon format

[cob59]

@Gm7468
Oui, ça me parait cohérent.
Note que XQuery laissera une plus grande liberté dans l'ordre d’initialisation des attributs de Point, et pourra même prévenir de l'absence d'un noeud XML (au lieu de laisser l'attribut à 0 ou non-initialisé, ce que peut être retors à debugger). Par contre ce ne sera pas aussi rapide qu'un bête "parcours" de l'arbre XML.

[Gm7468]

Je vous remercie pour toutes ces réponses.
Je pense que le tout est à présent à peu près clair pour moi, je n'ai plus qu'à créer la classe d'objet et les méthodes de lecture/écriture dans les classes correspondantes!

Merci!