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.