Discussion :

[NoIdea]

Bonjour à tous, je ne pense pas que ce que je souhaite faire est réalisable, mais on ne sait jamais.

J'aimerais introduire un système d'évènement. Le système actuel consiste à faire un emit("nom de l'évènement",/*paramètres*/); (les paramètres sont à nombre indéterminés (utilisation de variadiques template)).

Mon problème :
Je ne peux savoir ou l'utilisateur voudra émettre : si je créé un objet Textbox, je peux décider de mettre un emit quand la valeur change, quand la textbox est cliquée,... mais je ne peux savoir lesquelles seront utiles à l'utilisateur. De plus, comment décider si il faut émettre au début de la fonction qui change la valeur( avant qu'elle ne change) ou à la fin (une fois qu'elle est changée)?

Les solutions :
-Solution que j'utilise actuellement mais qui ne me satisfait pas : je met des emit "un peu partout" en espérant que l'utilisateur trouvera ce qu'il veut.
-Obligé l'utilisateur à passer par un parser (de mon invention), qui trouvera la macro SetEventEmission(nom de la fonction, END ou BEGIN voire numéro de ligne, nom de l'évènement, paramètres éventuels); Le parser rajoutera la ligne de code nécéssaire. Cette solution ne me satisfait pas : obliger de passer par un parser + coder le parser.
-Trouver avec le préprocesseur un moyen intelligent de rajouter ce genre de macro. Défaut : pas encore trouvé comment faire.

L'objectif : pouvoir définir la macro :

-SetEventEmission(nom_de_la_fonction,Numéro de ligne / Begin/End (juste avant le return), nom_de_l'évènement,paramètres);

Ainsi, plus besoin d'écrire aucun emit, c'est l'utilisateur qui choisit.

Ma question : Peut-on faire sa avec le préprocesseur ? Si oui, comment ? Si non, existe-il un moyen alternatif ?

Merci d'avoir pris le temps de lire le post, en espérant que vous m'ayez compris.

[Joel F]

et pourquoi pas faire une vrai fonction avec un emit dedans ?

[jblecanard]

Salut

Les solutions :
-Solution que j'utilise actuellement mais qui ne me satisfait pas : je met des emit "un peu partout" en espérant que l'utilisateur trouvera ce qu'il veut.

C'est ce que la grande majorité des systèmes à évènements font. Les évènements sont toujours émit et l'utilisateur s'abonnent à ceux dont il a besoin.

Sinon, tu peux regarder du côté de la programmation par aspect, ça risque de t'intéresser et il existe des outils de programmation par aspect pour C++.

[NoIdea]

J'ai regardé rapidement en quoi consistait la programmation par aspect, et je dois dire que je n'ai pas vu les moyens techniques pour faire ce que je voulais.
Je sais bien que la majorité des systèmes évènementiels utilisent le système que je fais actuellement. Cependant, ce n'est pas parce que tout le monde fait sa qu'on ne peut pas faire autrement...
Je cherche donc un autre moyen de faire.

Joel F, je n'est pas bien saisit ce que tu proposes. Pourrais tu expliciter ?

[jblecanard]

Je sais bien que la majorité des systèmes évènementiels utilisent le système que je fais actuellement. Cependant, ce n'est pas parce que tout le monde fait sa qu'on ne peut pas faire autrement...
Je cherche donc un autre moyen de faire.

C'est louable, mais vu la maturité de pas mal de systèmes et de softs qui utilisent ce principe, il faut aussi se dire qu'il y a sûrement une bonne raison L'intérêt est que tu choisis toi même les évènements pertinents, et que tu encadres l'utilisateur en ne lui en donnant pas trop.

Si c'est le coût en performance d'envoi d'évènement auxquels personne n'est abonné qui t'inquiète, tu peux le réduire drastiquement en utilisant un système avec des foncteurs.

Avec ton idée, l'utilisateur devient intrusif dans ton implémentation, et je pense que ce n'est pas très sain.

[NoIdea]

Je pense que la bonne raison dont tu parles est la simplicité pour l'utilisateur (ce dont je me souci peu : je ne créé pas forcément cette GUI pour quelqu'un d'autre). De plus, on pourrait faire remarquer que beaucoup de système utilisent des void* pour les paramètres à la fonction. Ce n'est pas mon cas (template variadique) grâce à c++0x. Je suis donc tout à fait ouvert au niveau des solutions : dépendances sur boost, c++0x, ... contrairement à la majorité des systèmes qui évitent les dépendances.

Aussi, si c'est possible, j'aimerais pouvoir fournir une telle fonction, peut être en addon (je continue à mettre mes evenements un peu partout et si cela ne convient pas à l'utilisateur, il change sa position ou en rajoute un autre).

Bien sur, s'il n'existe pas de solution, je ne chercherais pas plus loin...

[3DArchi]

Salut,
En quoi un Boost.Signal ne te satisfait pas ? Si personne n'est abonné, le message est simplement ignoré non ?
Sinon, une approche par aspect me semble aussi une bonne idée.