Discussion :

[agrosjea]

Bonjour,

Pour ceux qui connaissent vvvv (sinon, allez voir c'est génial, mais c'est sous windobe), je suis en train d'expérimenter l'implémentation d'un tel système en C++ sous linux.
J'ai donc créé une petite structure de graphe de boites que je peux connecter entre elles. Chaque Boite (classe abstraite) a des entrées sorties et une manière propre de se runner (implémentée dans les classes fille).
Aussi je souhaiterais sauvegarder la topologie de mon graphe dans un fichier XML. Jusque la, pas vraiment de problème en utilisant boost::serialization ca devrait se régler assez rapidement.

Mon problème sera de recharger le fichier. Comment créer la bonne boite au rechargement étant donné que C++ n'est pas réflexif. La solution serait de faire une sorte de palette de boite qui associerait une chaine de caractère à une implémentation, mais je ne trouve pas cela très flexible.

En effet j'aimerais, à la manière de VVVV ne pas fixer le nombre de boites possibles, les utilisateurs pourraient ainsi rajouter un fichier *.so ou *.dll dans le dossier plugin et disposer de leur nouvelle boite.

Est-ce possible av C++ ? Faut-il passer par un autre langage (type C# ou java) ? Dans cas, dois-je tout réecrire dans le langage en question ou puis-je écrire juste la partie de loading ?

Si je ne suis pas assez clair n'hésitez pas à me demander des précisions...

Merci de votre aide.

[Joel F]

si tu sauves avec serialization, elle s'occupe deja de remonter tout proprement.

[poukill]

Dans mon projet j'avais fait quasiment exactement ça : des objets stockés sous XML (mais pas avec boost::serialization).
Le rappel de ces objets se fait via une factory, nul besoin de réflexivité.

Je connais juste les bases de boost.Serialization, Si ça fait tout (dixit Joel), alors bingo.

[Invité]

Comme pukill, je fais ce genre de chose pour le boulot : une factory qui créé les objets à la volée, avec une initialisation faite sur les paramètres obtenus par la sérialisation.

La réflexivité peut être utile dans la factory, pour identifier facilement la classe à générer (par son nom, par exemple).

[poukill]

De toute façon dans une factory faut bien faire un REGISTER un jour. Donc factory classique à base std::map<string, boost::function> où bien bibliothèque de réflexivité (CAMP par exemple), ça revient à peu près au même.
Disons que la réflexivité en C++ permet bien plus que ça, alors c'est un peu "overkill" si t'as juste besoin d'une factory.

[agrosjea]

Oulala, ca m'a l'air vraiment compliqué du coup, j'ai vraiment été pourri par le java. Du coup j'en viens à me demander comment fonctionnent les systèmes de plugins dans des applications type codeblocks gedit et autre...

Je vais peut-etre tout de meme aller voir du côté de CAMP.

[JulienDuSud]

Le système de plugins n'a aucun rapport avec la reflexivité.

Un plugin (.dll ou .so ou peu importe) c'est juste pour lancer du code qui n'est pas dans l'executable. En gros tu lie dynamiquement des librairies à ton application, à la volée.

Ce que tu fais là, c'est de la serialization, ce qui est encore différent de la réflexivité. Ton fichier XML qui correspond donc à tes objets serialisés doit suivre une certaine structure. Par exemple, les objets de type A tu les mets dans une balise <A></A> et tu complètes par des attributs d'état. Pareil pour des objets de type B, C etc...

Lorsque tu déserialises, tu fais la même chose dans le sens inverse: tu lis le fichier, et si tu lis <A> tu sais que tu vas devoir initialiser un objet de type A avec les attributs qui sont dans le fichier XML, si tu lis un objet de type B pareil, etc etc...

La réflexion, c'est pour par exemple crée un langage de scripting qui pourra être lu par l'application et ainsi créer des objets à la volée suivant une certaine logique. Pas vraiment de sérialisation là dedans.