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.