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.

[NoIdea]

Boost.Signals ne me suffit pas pour plusieurs raisons.

Si personne n'est abonné, le message est simplement ignoré non ?

C'est la cas avec mon système actuel. Cependant, si je veux placé un emit la ou ce n'est pas prédéfini, il faut modifier le code source.

[3DArchi]

Cependant, si je veux placé un emit la ou ce n'est pas prédéfini, il faut modifier le code source.

Cela t'oblige de toute façon à exposer les détails d'implémentation de tes fonctions si tu souhaites que l'utilisateur puisse mettre l'émission de l'évènement n'importe où.

[NoIdea]

Cela t'oblige de toute façon à exposer les détails d'implémentation de tes fonctions si tu souhaites que l'utilisateur puisse mettre l'émission de l'évènement n'importe où.

En effet, je ne vois pas le moyen de faire autrement. Cependant, ceci n'est pas un problème majeur. Y a t-il une solution en utilisant __LINE__ pour insérer du code à la ligne donnée ?

[jblecanard]

Ca voudrait en plus dire que certains fichiers C++ vont être responsables de la modification d'autres fichiers C++ ? Et que va-t-il se passer s'ils ont été compilés avant ? Un bordel monstre assurément.

Je ne vois rien d'autre qu'un préprocesseur maison exécuté sur tous les fichiers avant ou de la programmation aspect.

[NoIdea]

Je ne vois rien d'autre qu'un préprocesseur maison exécuté sur tous les fichiers avant ou de la programmation aspect.

Il doit y avoir quelque chose que je n'ai pas compris :
Il faut bien l'implémenter la programmation par aspect en c++ ! Ce n'est donc pas une solution, il s'agit juste de l'équivalent d'un pattern. Pourriez vous m'éclairer sur ce point ?

Quant-à la deuxième solution, je préfère garder le système actuelle que de faire un préprocesseur maison.

Il n'y a donc pas de solution ?

[jblecanard]

Salut

Il faut bien l'implémenter la programmation par aspect en c++ ! Ce n'est donc pas une solution, il s'agit juste de l'équivalent d'un pattern.

Non je pense que tu n'as pas compris. Pour simplifier, la programmation par aspect te permet de rajouter des traitements (du code) à des points précis, par exemple, avant l’exécution d'une méthode, ou après, et ce depuis un fichier externe. Ces points sont ce qu'on appelle des "joint points", il y en a d'autres (je ne suis pas spécialiste).

Par contre les outils existent déjà et feront eux même la génération de code. Par exemple, tu peux créer un aspect qui va loguer tous les appels des méthodes d'un type donné. D'un point de vue compilation, il y a bien une étape de pré-processing, mais tu n'as pas à l'écrire toi même

[NoIdea]

Par contre les outils existent déjà et feront eux même la génération de code. Par exemple, tu peux créer un aspect qui va loguer tous les appels des méthodes d'un type donné. D'un point de vue compilation, il y a bien une étape de pré-processing, mais tu n'as pas à l'écrire toi même

C'est la deuxième chose plausible à laquelle j'avais pensé. Cependant, elle oblige donc mon utilisateur a appelé autre chose que le compilateur lors de la compilation. C'est la chose qui me rebute le plus avec Qt (appelé qmake) et je ne souhaite pas introduire un tel système. Merci tout de même. Je pense qu'il n'y a pas d'autre solution et je vais clore le sujet. N'hésitez pas à écrire quelque chose si vous avez une idée, je "deresolurait" le sujet...

Merci.

[koala01]

Salut,

En fait, il serait peut être possible de faire quelque chose sous la forme de plusieurs instructions préprocesseur proches de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#define SIGNAL0(x) void on_##x()\
{\
    /* action à effectuer */\
}
#define SIGNAL1(x arg1 name1) void on_##x(arg1 name1)\
{\
     /* action à effectuer */\
}
#define SIGNAL2(x arg1 name1 arg2 name2) void on_##x(arg1 name1, arg2 name2)\
{\
    /* action à effectuer */\
} 
#define DEFAULTSIGNALS\
public:\
SIGNAL0(click)\
SIGNAL0(redraw)\
SIGNAL0(update)\
SIGNAL2(mouseIn  int  x  int y)\
SIGNAL2(mouseOut  int, x  int y)\
SIGNAL2(mouseMove  int  x  int y)

que tu pourrais utiliser sous une forme proche de

Code :

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

1
2
3
4
class MyClass
{
    DEFAULTSIGNALS
};

Et, pour les classes qui auraient besoin de signaux particulier, tu profiterais des définitions de SINALxxx

Mais n'est)ce pas se faire un peu beaucoup de mal pour pas grand chose

[3DArchi]

C'est la deuxième chose plausible à laquelle j'avais pensé. Cependant, elle oblige donc mon utilisateur a appelé autre chose que le compilateur lors de la compilation. C'est la chose qui me rebute le plus avec Qt (appelé qmake) et je ne souhaite pas introduire un tel système. Merci tout de même. Je pense qu'il n'y a pas d'autre solution et je vais clore le sujet. N'hésitez pas à écrire quelque chose si vous avez une idée, je "deresolurait" le sujet...

Merci.

Dans le fond, je me demande franchement s'il ne s'agit pas d'une fausse feature (YAGNI comme dirait l'autre). Les évènements émis par ton framework restent prédéterminés par son architecture et son 'ouverture'. Je vois pas l'utilité de pouvoir customiser l'envoi de l'évènement à la ligne d'instruction près.

[NoIdea]

Mais n'est)ce pas se faire un peu beaucoup de mal pour pas grand chose

Je commence à penser que c'est vrai. Merci de votre aide. Je vais rester avec un système standard.