Discussion :

[j-jorge]

Bonjour,

J'ai commencé à écrire un article sur un système permettant d'«*exporter*» des méthodes d'une classe de manière à pouvoir les appeler en passant leur nom et leurs paramètres sous forme de chaînes de caractères. J'ai implémenté ce système mais je me perds dans la rédaction*; je ne sais pas dans quel ordre présenter les éléments.

L'intérêt de ce système est justifié dans une situation où les méthodes et données sont entrées par l'utilisateur. Par exemple, imaginons un logiciel de traitement d'image en gros, nommé batch-img, pour lequel la classe d'image propose ces opérations classiques*:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class image
{
public:
  /* Applique une rotation d'angle a à l'image, autour du centre aux
     coordonnées (cx, cy). */
  void tourner( double a, int cx, int cy );
 
  /* Retourne l'image horizontalement. */
  void miroir();
 
  /* Copie l'image img sur l'image courante, à la position (x, y). */
  void copier( image* img, int x, int y );
 
}; // class image

On aimerait utiliser ce logiciel en ligne de commande pour effectuer des traitements sur des images. En particulier, on aimerait que l'utilisateur puisse écrire des petits scripts comme celui ci-dessous, qu'il passerait au programme.

image_1 miroir
image_2 tourner 18.6 24 -16
image_1 copier image_2 700 30
image_1 miroir

L'utilisateur pourrait appliquer ce script à des images avec une
commande comme celle-ci:

batch-img image_1=fred.jpg image_2=moscou.jpg traitement.txt

J'ai fait deux implémentations, une simple où les paramètres des méthodes exportées ne peuvent être constants, ni des pointeurs ou des références, et une autre un peu plus compliquée où ces types sont autorisés.

Le système peut paraître lourd à mettre en place, mais lorsque le cœur est écrit, il suffit d'une seule ligne par méthode pour permettre de l'appeler par son nom. De plus, l'export ce fait dans l'environnement de la classe exportée. Ainsi, lorsqu'une nouvelle méthode est exportée, il n'est pas nécessaire de retrouver une fonction de conversion dans un fichier éloigné et elle est immédiatement accessible à l'utilisateur.

J'aimerais avoir vos commentaires et vos conseils pour la rédaction et la forme de l'article. Est-ce que le sujet vous semble pertinent*? Est-ce que la technique vous semble correcte*?

De plus, j'ai implémenté ceci sans savoir si cela existait et j'aimerais savoir si ça correspond à quelque chose de connu.

[Laurent Gomila]

Ca ressemble un peu à ça non ?
http://www.developpez.net/forums/d80...reflexion-cpp/

[j-jorge]

Ca ressemble un peu à ça non ?
http://www.developpez.net/forums/d80...reflexion-cpp/

Ça y ressemble oui, avec beaucoup plus de fonctionnalités (du côté de CAMP). Mais il y a quelques petites différences qui me perturbent.

Je donne un peu le contexte dans lequel j'ai codé cela, afin que vous puissiez m'indiquer si CAMP, que je ne connaissais pas, peut combler mes besoins et donc remplacer ce code.

J'ai un projet de jeu dans lequel je souhaite intégrer un petit système de script pour les personnages, de manière à faire des petites scènes se déroulant dans le style d'une pièce de théâtre. C'est à dire que les personnages doivent effectuer des actions à des moments précis et dans un ordre donné. L'idée est d'illustrer un peu avec des scène clés du scénario. Nous avions initialement pensé à utiliser Lua, mais nous sommes arrivés à la conclusion que c'était totalement démesuré (nous n'avons pas besoin de structures de contrôles par exemple) et le fait de devoir dupliquer les méthodes pour faire une version code et une version Lua avec contexte d'exécution nous a semblé peu pratique.

J'ai donc écrit ce code qui va nous permettre de faire ce genre de fichiers texte, où le premier nombre indique la date de l'action et où tous les intervenants sont connus au début de la scène*:
0.10 joueur.rejoindre(repère_1);
1 ennemi.attaquer(joueur);
1.5 joueur.dire("argh !");
1.5 ennemi.rejoindre(repère_2);

Nous avons donc des méthodes et des paramètres en texte, à appliquer sur des objets que nous ne connaissons qu'à peine (nous savons juste qu'ils héritent d'une même classe). Dans le code que j'ai posté, les paramètres de la méthode appelée sont passés par un tableau de chaînes de caractères. Je trouve cela pratique dans le sens où il n'est pas nécessaire de connaître leur nombre et leur type pour exécuter la méthode (il y a quand même une vérification avant la conversion). Je me demande quel est le coût pour arriver à un résultat similaire avec CAMP. En effet, dans le lien que vous avez posté, les méthodes sont appelés avec la liste de paramètres donnés selon les types déclarés.

De même, j'aime assez le côté non intrusif de CAMP, mais je me demande où et comment enregistrer les classes (la première instruction du main() que du lien que vous avez envoyé). En particulier, quand il s'agit d'une classe qui provient d'un autre module, inconnu du moteur du jeu. Un point qui me plaît dans le code que j'ai écrit est qu'il est possible d'exporter une classe d'une manière indépendante du reste du programme.

Je suis intéressé par vos commentaires sur ces interrogations et sur la technique. Aussi, pensez-vous que cela vaille le coup de continuer l'article*?

[3DArchi]

Ça y ressemble oui, avec beaucoup plus de fonctionnalités. Mais il y a quelques petites différences qui me perturbent.

Je donne un peu le contexte dans lequel j'ai codé cela, afin que vous puissiez m'indiquer si CAMP, que je ne connaissais pas, peut combler mes besoins et donc remplacer ce code.

J'ai un projet de jeu dans lequel je souhaite intégrer un petit système de script pour les personnages, de manière à faire des petites scènes se déroulant dans le style d'une pièce de théâtre. C'est à dire que les personnages doivent effectuer des actions à des moments précis et dans un ordre donné. L'idée est d'illustrer un peu avec des scène clés du scénario. Nous avions initialement pensé à utiliser Lua, mais nous sommes arrivés à la conclusion que c'était totalement démesuré (nous n'avons pas besoin de structures de contrôles par exemple) et le fait de devoir dupliquer les méthodes pour faire une version code et une version Lua avec contexte d'exécution nous a semblé peu pratique.

J'ai donc écrit ce code qui va nous permettre de faire ce genre de fichiers texte, où le premier nombre indique la date de l'action et où tous les intervenants sont connus au début de la scène*:
0.10 joueur.rejoindre(repère_1);
1 ennemi.attaquer(joueur);
1.5 joueur.dire("argh !");
1.5 ennemi.rejoindre(repère_2);

Nous avons donc des méthodes et des paramètres en texte, à appliquer sur des objets que nous ne connaissons qu'à peine (nous savons juste qu'ils héritent d'une même classe). Dans le code que j'ai posté, les paramètres de la méthode appelée sont passés par un tableau de chaînes de caractères. Je trouve cela pratique dans le sens où il n'est pas nécessaire de connaître leur nombre et leur type pour exécuter la méthode (il y a quand même une vérification avant la conversion). Je me demande quel est le coût pour arriver à un résultat similaire avec CAMP. En effet, dans le lien que vous avez posté, les méthodes sont appelés avec la liste de paramètres donnés selon les types déclarés.

De même, j'aime assez le côté non intrusif de CAMP, mais je me demande où et comment enregistrer les classes (la première instruction du main() que du lien que vous avez envoyé). En particulier, quand il s'agit d'une classe qui provient d'un autre module, inconnu du moteur du jeu. Un point qui me plaît dans le code que j'ai écrit est qu'il est possible d'exporter une classe d'une manière indépendante du reste du programme.

Je suis intéressé par vos commentaires sur ces interrogations et sur la technique. Aussi, pensez-vous que cela vaille le coup de continuer l'article*?

Salut,
De ce que j'ai vu de CAMP et de ce que tu décris, je pense que cela pourra faire l'affaire. Après, il y a un coût pour rentrer dans CAMP, mais le coût de dev. d'une solution maison sera-t-il inférieur ?
Sinon pour l'article, c'est cent fois OUI :
-> Si tu pars sur une solution 'home-made', alors oui ça peut intéresser de voir comment vous la mettez en œuvre ;
-> Si tu pars sur CAMP, alors oui : ça peut faire un tutoriel d'introduction à l'utilisation de CAMP.

D'autres pistes sur ce que tu veux faire, peut être de passer par Boost.Python et si besoin d'embarquer Python dans ton jeu. Et là encore, un tutoriel montrant comment tout ça est mis en œuvre, ce ne serait que du bonheur.

J'ai survolé ton ébauche d'article. Globalement, il m'a l'air bien parti. Les idées sont avancées au fur et à mesure, les problèmes expliqués et la solution choisie présentée. Je ne me suis pas attardé sur l'aspect technique pour voir s'il y avait des problèmes de ce côté. Un peu plus tard.

Bon courage.

[Laurent Gomila]

Dans le code que j'ai posté, les paramètres de la méthode appelée sont passés par un tableau de chaînes de caractères. Je trouve cela pratique dans le sens où il n'est pas nécessaire de connaître leur nombre et leur type pour exécuter la méthode (il y a quand même une vérification avant la conversion). Je me demande quel est le coût pour arriver à un résultat similaire avec CAMP. En effet, dans le lien que vous avez posté, les méthodes sont appelés avec la liste de paramètres donnés selon les types déclarés.

Ca ne pose pas de problème :
- Si le type réel est convertible à partir d'une chaîne alors on pourra passer le paramète sous forme de chaîne
- Les paramètres sont passés via un objet camp::Args, qui est plus ou moins un tableau dynamique donc aucun problème concernant le nombre de paramètres

De même, j'aime assez le côté non intrusif de CAMP, mais je me demande où et comment enregistrer les classes (la première instruction du main() que du lien que vous avez envoyé). En particulier, quand il s'agit d'une classe qui provient d'un autre module, inconnu du moteur du jeu. Un point qui me plaît dans le code que j'ai écrit est qu'il est possible d'exporter une classe d'une manière indépendante du reste du programme.

Là aussi c'est prévu : lorsque tu déclares un type, tu peux lui donner la fonction qui va déclarer la metaclasse (via la macro CAMP_AUTO_TYPE au lieu de CAMP_TYPE) ; dans ce cas la fonction sera appelée automatiquement par CAMP lorsqu'il en aura besoin, et tu ne seras pas obligé de la caser quelque part dans ton flux d'exécution.