Discussion :

[gege2009]

Bonjour,

J'aimerais avoir un avis sur la façon de procéder quant à la création d'un arbre d'objets qui peut être cyclique. L'idée est que j'ai par exemple un fichier XML qui décrit les dépendances entre les objets et que je représente en mémoire via des classes C++.

Je pensais à un gestionnaire G à qui on demande un objet, s'il n existe pas déjà on le crée et on le rajoute dans une pile, sinon on le restitue, car présent dans la pile, pour le brancher. Du coup ce gestionnaire doit gérer des listes typées d'objets, imaginons des set<A>, set<B>, etc.

Je trouve ça assez lourd de créer des méthodes d'accès, de stockage pour chaque objet au sein du gestionnaire

A G::getA( ... ) --> parcourt un set<A>
B G::getB( ... ) --> parcourt un set<B>

Existe-t-il une façon de faire plus optimale ? J'imagine que c'est un problème assez récurrent en fait, mais j'ai du mal à le qualifier.

Merci d'avance

[Invité]

Bonjour,
J'ai pas vraiment (ou pas du tout) compris votre problème.
D'abord, le terme "cyclique" m'étonne pour un arbre. Ce serait plutôt un graphe.
L'organisation d'un fichier XML est très précise
<balise d'ouverture>
... n'importe quoi
<balise de fermeture>
Dans le "n'importe quoi", il peut y avoir des choses qui on été déjà vues, mais ces différents éléments identiques sont indépendants.
Si comme je le crois, vous cherchez à faire une base de données, je ne pense pas que ce soit le bon sous-forum. Ce que vous voulez faire doit être complètement indépendant du langage utilisé.

En d'autres termes, il faudrait d'abord évaluer, décrire et préciser vos besoins (points - lignes - zones - objets - textes) puis décrire leur organisation, la méthode de stockage etc. Ensuite seulement vous pourrez vous préoccuper du langage à utiliser.

[gege2009]

Ok, si ce n'est pas clair, je vais donner un exemple alors :

Voici un exemple de fichier XML :

Code :

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

1
2
3
4
5
<description>
  <objet type="voiture" name="V1" moteur="M" />
  <objet type="voiture" name="V2" moteur="M" />
  <objet type="moteur"  name="M" />
</description>

Côté code, j'aurais ces classes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class voiture
{
  private: 
    string _name;
    moteur * _m;
};
 
class moteur
{
  private: 
    string _name;
};

Et l'idée est donc d'instancier des objets de sorte à reproduire ma description XML en lisant dynamiquement mon XML.

Ici il faut créer 2 voitures distinctes qui pointent vers un même moteur .

[Invité]

Bon, donc, c'est bien ce que j'avais cru comprendre.
Le terme "fichier de configuration" n'est pas vraiment approprié.

Donc vous allez avoir une gestion de garage (pour garder l'exemple)
Il y a un certain nombre de types de moteurs. Ces moteurs ont tous un carburateur, mais il y a un certain nombre de marques, ce qui entraine une gestion des carburateurs.

Le premier problème à résoudre, ou à préciser : que voulez-vous faire de tout cela ?
Quand ce sera précisé, la question à se poser : comment gérer ces informations? en mémoire? avec une base SQL, en accès disque sans BD, ou autrement ?
Quelles seront les actions à faire sur ces différents éléments?
Enfin, pour pouvoir éteindre la machine et sauvegarder le tout, résoudre les problèmes de lecture - écriture.

[gege2009]

Une fois mon système créé, je le fais tourner

Code :

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

1
2
3
 
voiture->Roule();
moteur->Tourne();

Le tout est d'arriver à créer ce système de la façon la plus élégante possible.

Je trouve le XML plus léger à embarquer à côté de l'EXE. Ca me permet de faire tourner l'EXE sur n'importe quel poste, sans avoir à se connecter à l'exterieur (ce qui n'est pas toujours possible). En plus il n'y aura qu'une dizaine d'objets.

[cs_ntd]

Bonjour,
Je crois avoir a peu près compris le problème, mais je en suis pas sûr de 2 ou 3 trucs encore :

Est-ce un problème de parsage ("l'idée est donc d'instancier des objets de sorte à reproduire ma description XML") ou sérialisation ("la création d'un arbre d'objets qui peut être cyclique"), ou les 2 ?
Tu lit le XML ou tu écrit dedans ?

Si c'est pour instancier des classes dynamiquement, je ne vois pas d'autres solutions que de faire :
- un set<Voiture>
- un set<Moteur>
- un set pour chaque type en fait
Et chaque élément du set<Voiture> référence un élement du set<Moteur>

Vu que les voitures références un moteur, tu lit le XML en cherchant les Moteurs, que tu insères dans ton set<Moteur>. Puis tu lit les voitures.

Si le probmème est d'écrire le fichier XML en fonctiond e ce que tu a en mémoire, ça dépend beacoup de ta représentation en mémoire. Si je reprend celle d'au-dessus, c'est assez simple, il suffit de parcourir les 2 set et d'écrire les éléments les 1 après les autres... Si il y des références cycliques (ce n'est pas le cas ici...), il faut introduire un système d'identifiant unique par exemple (i y a sûrement d'autres manières de procéder, mais celle là est assez simple a mettre en place...).

[Invité]

Encore une fois, j'ai un peu de mal à suivre.
Question d'élégance, l'informatique, c'est bêtement utilitaire. Il vaut mieux que ça marche sans élégance plutôt que ne pas marcher avec élégance.

Je trouve le XML plus léger à embarquer à côté de l'EXE.

Là, je suis complètement perdu. Un fichier XML est un fichier de données, un EXE est un binaire exécutable. Je n'imagine pas comment on peut comparer ces deux types de fichiers.

[gege2009]

Je pars d'un XML, je le parse pour créer mon graph, je fais mes bidouilles, et enfin j'écris les résultats dans le XML.

La difficulté est que quand je fais les voitures, puis le moteur, ensuite il faut faire les liaisons donc il faut itérer sur une structure d'objets pour trouver l'objet correspondant, ici le moteur M dans le set<Moteur>.

Actuellement, je procède comme ça, mais je trouvais un peu lourd le fait de créer un set par type d'objet. Mais peut-être que c'est la seule solution ...

Merci pour avoir penché sur mon cas en tout cas.

[cs_ntd]

Là, je suis complètement perdu. Un fichier XML est un fichier de données, un EXE est un binaire exécutable. Je n'imagine pas comment on peut comparer ces deux types de fichiers.

Je crois qu'il voulait dire que le XML était plus léger au niveau de la conception/utilisation que de faire une base de donnée...

"XML plus léger (qu'une DB) à cotés d'un EXE"...

@gege2009:
J'en profite pour partir sur un truc :
Le fichier XML, je ne le trouve pas beau .

Ca serait plus "élégant" de faire ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<Garage>
    <voiture nom="..." modele="..." moteur="..." /> //Edit : J'avais oublié les moteurs :-D
    <voiture nom="..." modele="..." moteur="..." />
    ...
</Garage>
<Moteurs>
    <moteur type="..." ...>
    <moteur type="..." ...>
</Moteurs>
<ModeleVoiture>
    <modeleVoiture modele="..." moteur=".." />
    <modeleVoiture modele="..." moteur=".." />
</ModeleVoiture>

C'est en tout cas plus réalistes : des modèles de moteurs, des modèles de voitures, et enfin des voitures d'un certains modele et avec un certain moteur, dans un garage.



Ensuite, ça :

Ici il faut créer 2 voitures distinctes qui pointent vers un même moteur

C'est absolument pas réaliste... Ca voudrait dire que 2 voitures utilisent le MEME moteur, la même instance du moteur... Si tu réelement tu cré bien un garage, je pense qu'il faut changer ça en :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class voiture
{
  private: 
    string _name;
    moteur _m; //Pas de pointeur, un moteur est propre a chaque voiture
};
 
class moteur
{
  private: 
    string _name;
};

Et ceci évite même d'avoir 2 set (<Voiture>, et <Moteur>).

Dans ce cas, Tu a juste un seul set<Voiture>.
Tu parcours ton XML, en cherchant des voitures, pour chaque voiture, tu va chercher le modele et le moteur correspondant dans le XML, et tu insere juste une voiture dans le set<Voiture>.

Et tu n'a qu'un seul set<>. Je pense que c'est la meilleure solution (disons que je n'en vois pas d'autre).

[gege2009]

OK, merci à toi et à Pierre (même si on ne se comprend visiblement pas du tout )