Je suis globalement d'accord avec toi, si ce n'est que...
A titre tout à fait personnel, j'exècre les callbacks
Et, quelque part, faut il rappeler que la politique du projet est, malgré tout, d'utiliser au mieux les méthodes "modernes" disponibles
De ce point de vue, boost.signals2 fournit (c'est du moins mon ressenti) une alternative valable et efficace à tout ce que l'on pourrait faire avec les callbacks qui, de mon avis (mais on peut en discuter, hein ) s'apparente à une manière de faire totalement préhistorique (re ).
Je proposerais donc de prendre le problème "par l'autre bout", pour ne pas dire "le prendre à l'envers" et que l'on essaye de réfléchir à la possibilité de faire en utilisant en priorité boost.signals, quitte à faire "marche arrière" et à revenir à des possibilités plus traditionnelles (callbacks) si l'on se rend compte que l'approche "moderne" pose plus de problèmes qu'elle n'apporte de réponses.
Je ne dis pas qu'il faut abandonner de manière systématique les callbacks, mais je souhaiterais que leur utilisation soit restreinte au stricte minimum et au plus près des fonctions dépendante du système (en gros, qu'il n'y ait pas de callbacks au-delà de la façade que nous devrons mettre en oeuvre pour faire cohabiter les différents systèmes).
Quelque part, si par la complexité de mise en place et de maintenance qu'implique signals2, on arrive à faciliter la vie de l'utilisateur, je vote sans réflexion pour la souplesseQuelques remarques d'ordre général sur le problème:
En fait, au niveau le plus abstrait, ce qu'il nous faut c'est que nos contrôles soient observables (DP observer), et que les observeurs puissent être implémentés par l'utilisateur. Il y a différentes techniques pour implémenter un observer (callback, signal/slot, événement), chacune ayant ses avantages et ses inconvénients. Par exemple, avec un système d'événement avec une FIFO de gestion de ces events, l'avantage est la souplesse et la facilité pour implémenter des animations. L'inconvénient c'est que c'est plus complexe à mettre en place (et donc à maintenir etc.).
Au niveau de l'application (TApplication et ses spécialisations ) on ne pourra pas éviter une boucle, cela me semble évident.Je pense qu'il faut commencer par répondre à des questions du style:
- Comment gérer les animations (par exemple une liste déroulante - combo - qui s'ouvre). Répondre à cette question nécessite répondre à la questions suivante:
- Va-t-on avoir besoin d'une boucle principale? Personnellement, je ne vois pas comment s'en passer.
Mais bon, nous pourrions très bien nous en sortir avec quelque chose proche de
Code C++ : 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
21 class TApplication { public: int run() { continue_=true; while(continue_) { /*...*/ } return returnCode_; } void onStopRequest(int returnCode=0) { continue_=0; returnCode_=returnCode; } private: int returnCode_; // la valeur de retour bool continue_; // pour savoir si on retourne dans la boucle };
On ne peut pas s'en passer, mais l'idéal est de les "enrober" de manière à ce qu'ils soient "formatés" pour l'utilisation une fois qu'ils ont passé le "barrage" de la façadeHa, et une précision: les événements de l'OS on ne peut pas s'en passer. C'est eux qui nous disent ce qu'il se passe (clic souris, touche clavier, etc.)
Partager