Appels de méthodes déterminés dynamiquement

Bonjour,

Je vous propose mon premier article, concernant un système en C++ pour appeler des méthodes dont le nom et les paramètres ne sont connus qu'à l'exécution.

Le synopsis est le suivant :

Citation:

---

Cet article présente une technique pour appeler des méthodes de certaines classes dans un système de type « script ». Dans une telle situation, les méthodes et leurs paramètres ne sont connus qu'à l'exécution, sous la forme de chaînes de caractères.

---

N'hésitez pas à laisser vos remarques et suggestions dans ce fil de discussion.

Merci

Salut,
C'est un article intéressant, bien expliqué et de bonne qualité. Le code présenté est clair et complet. :ccool:

Tu t'en sers pour rendre tes applications scriptables ? Quels types d'utilisations as-tu ?

Citation:

---

Envoyé par 3DArchi

Salut,
C'est un article intéressant, bien expliqué et de bonne qualité. Le code présenté est clair et complet. :ccool:

Tu t'en sers pour rendre tes applications scriptables ? Quels types d'utilisations as-tu ?

---

Merci pour ces commentaires. Nous utilisons en effet ce système pour scripter des scènes dans notre jeu. L'idée de départ était de pouvoir contrôler les personnages comme dans une pièce de théâtre, c'est-à-dire que les actions se font en séquence et que le déroulement de la scène est déterminé à l'avance. Cela signifie en particulier qu'il n'y a pas de structures de contrôle (conditionnelle, boucle). Nous avons donc des fichiers décrivant la scène par une série d'appels à des fonctions sur des objets connus. Par exemple :

Citation:

---

0 camera.smooth_activate(0.5);
0 player_1.stop();
0 player_2.stop();
0.1 player_1.do_action(move_right,0.6);
0.1 bridge.activate();

---

Nous nous étions initialement penché sur LUA pour scripter les scènes, mais son intégration nous a semblé trop coûteuse. Nous avons donc mis en place le système de cet article, en nous inspirant de la solution utilisée dans wxWidgets pour construire la table des méthodes exportées. Le résultat est moins puissant que LUA mais couvre parfaitement nos besoins. Au final, le seul coût pour utiliser une méthode dans un script consiste à hériter de 'base_exportable' et d'ajouter une ligne pour effectuer l'export.

De plus, c'était très intéressant à mettre en place :)

Cela se rapproche de mes besoins, si ce n'est que moi c'est dans un cadre factory >< !

En gros, j'ai un fichier (pareil) ou on spécifie les implémentation de types divers et leurs arguments... Le but et de parsé se fichier, tout en tenant en compte de l'évolutivité du truc.

En gros, l'idée et pour la classe utilisatrice de faire create(string,vector<any>) et pour les dites classes, ne mettre du code que dans leur fichier respectif >< !

J'avoue je coince un peu... J'ai réussi à faire en sorte de ne "pas" les initialisé dans l'objet "maître", mais je souffre d'un affreux paradoxe... Dont je discuterai peut-être plus tard :P !

En tout cas, je vais voir si je peux pas m'inspirer un peu de ce que tu fais ^^ !

Article très intéressant ! Ca nous change un peu du style d'article habituel.

Tout d'abord, j'veux bien te croire quand tu dis que c'était intéressant à mettre en place. D'autre part... as-tu prévu une "suite" à cet article ? C'est à dire utilisation de ce système pour quelque chose de plus gros par exemple ? Un langage plus "complet", avec JIT compilation ? :mrgreen:

Merci beaucoup en tout cas pour celui-là déjà :ccool:

Citation:

---

Envoyé par j-jorge

Nous nous étions initialement penché sur LUA pour scripter les scènes, mais son intégration nous a semblé trop coûteuse.

---

Est ce que vous aviez regardé du côte de Boost.Python ? Il me semble que ça aurait aussi permis d'ouvrir l'appli vers des scripts python. En plus vous êtes déjà en wxWidgets dis-tu et il y a un binding vers Python de cette bibliothèque.

Citation:

---

Envoyé par j-jorge

De plus, c'était très intéressant à mettre en place :)

---

C'est en forgeant...

Citation:

---

Envoyé par Lavock

Cela se rapproche de mes besoins, si ce n'est que moi c'est dans un cadre factory >< !

En gros, j'ai un fichier (pareil) ou on spécifie les implémentation de types divers et leurs arguments... Le but et de parsé se fichier, tout en tenant en compte de l'évolutivité du truc.

En gros, l'idée et pour la classe utilisatrice de faire create(string,vector<any>) et pour les dites classes, ne mettre du code que dans leur fichier respectif >< !

J'avoue je coince un peu... J'ai réussi à faire en sorte de ne "pas" les initialisé dans l'objet "maître", mais je souffre d'un affreux paradoxe... Dont je discuterai peut-être plus tard :P !

En tout cas, je vais voir si je peux pas m'inspirer un peu de ce que tu fais ^^ !

---

J'ai peut être mal compris, mais ça se résume pas à l'object factory de loki ça? pouvoir créer des objets sans connaitre leur type / ou avec une forme non-compatible avec la syntaxe C++? (fichier, string etc)

Justement, je suis en train de regarder. Mais pas sur que ça fasse TOUT ce que je veuille. Je ferai un autre thread si nécessaire.

Citation:

---

Envoyé par Alp

Article très intéressant ! Ca nous change un peu du style d'article habituel.

Tout d'abord, j'veux bien te croire quand tu dis que c'était intéressant à mettre en place. D'autre part... as-tu prévu une "suite" à cet article ? C'est à dire utilisation de ce système pour quelque chose de plus gros par exemple ? Un langage plus "complet", avec JIT compilation ? :mrgreen:

Merci beaucoup en tout cas pour celui-là déjà :ccool:

---

Merci pour ces retours. A priori, ce système répond bien à nos besoins, il ne devrait plus grossir. Du coup, le prochain article sera sur un tout autre sujet, mais c'est une surprise… dont je parle dans un autre post :)

Citation:

---

Envoyé par 3DArchi

Est ce que vous aviez regardé du côte de Boost.Python ? Il me semble que ça aurait aussi permis d'ouvrir l'appli vers des scripts python. En plus vous êtes déjà en wxWidgets dis-tu et il y a un binding vers Python de cette bibliothèque.

---

Je ne me souviens pas avoir regardé du côté de Boost.Python, mais c'est peut être juste parce que je n'apprécie pas de programmer dans ce langage. Je crois que nous avions trouvé un autre système du type LUA, mais je ne me souviens pas du langage. Peut-être du php… Dans tous les cas, ce sont des solutions un peu démesurée pour les petits scripts que nous voulons faire.

Merci pour l'article.

Bien vu pour la template, je me demandais comment on pouvait faire ça "proprement" sans monter une hiérarchie en arbre avec un "Object" au sommet, comme dans Qt, Java, dot net,...

Citation:

---

Envoyé par Lavock

En gros, l'idée et pour la classe utilisatrice de faire create(string,vector<any>) et pour les dites classes, ne mettre du code que dans leur fichier respectif >< !

---

La méthode de la template doit difficilement s'appliquer. Un méthode "java" like doit mieux convenir...

Le tout est de pouvoir connaitre le type de Object pour savoir comment caster dans "create" par exemple. Il faut l'équivalent de instanceof pour ceci.

Pour ceux que ça intéresse :

- QObject de chez Qt, qui permet de coder un arbre d'héritage, semble donner une bonne idée de comment y parvenir. Même si "inherits" est pas idéal pour les performances...
http://qt.developpez.com/doc/latest/...bjectname-prop

- Regarder comment s'articule les classes Java : "Object" et "Class" permet de se faire une bonne idée de comment monter un interpréteur pour un langage objet en C/C++

Article très intéressant, et très bien écrit !
Toutefois, n'y a-t-il pas une faut d'accord dans le titre (car on dit une méthode, non un méthode) ?

On dit même : "une fonction membre".
Dans le glossaire de la bible, "méthode" == "fonction membre virtuelle", donc autant éviter le terme vu que pour quantité d'autres personnes, le "virtuel" n'est pas implicite quand ils parlent de "méthode".

Citation:

---

Envoyé par Amnell

Article très intéressant, et très bien écrit !
Toutefois, n'y a-t-il pas une faut d'accord dans le titre (car on dit une méthode, non un méthode) ?

---

Je l'avais écrit en pensant que ce sont les appels qui sont déterminés à l'exécution. C'est ambiguë mais je n'avais pas trouvé d'autre formulation.