IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Farfelue Discussion :

quelques petites questions


Sujet :

Farfelue

  1. #21
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    Citation Envoyé par r0d Voir le message
    Cette histoire de [signal][event][callback] (choisissez l'option que vous voulez, de toutes façon ce sont des notions différentes mais dans notre cas l'objectif est le même) n'est en effet pas si simple. Techniquement il n'y a rien de compliqué, je pense qu'on peut même s'en sortir avec boost::function (avec une map de boost::fonction par exemple si on veut plusieurs observeurs), mais c'est au niveau de la conception qu'il ne faut pas se planter.

    Je crois que la meilleure solution dépends de ce que l'on veut faire, et qu'une fois qu'on aura bien déterminé ce que l'on veut faire, le choix nous paraitra évident.
    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).
    Quelques 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.).
    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 souplesse

    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.
    Au niveau de l'application (TApplication et ses spécialisations ) on ne pourra pas éviter une boucle, cela me semble évident.

    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
    };

    Ha, 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.)
    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çade
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #22
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    4 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : août 2004
    Messages : 4 261
    Points : 6 667
    Points
    6 667
    Billets dans le blog
    2
    Par défaut
    Ok, ton point de vue me convient
    Je ne connais pas boost.signal, je vais aller y jeter un coup d'oeil tout de suite pour m'assurer que c'est bien ce que je crois.
    Une classe Application me semble une bonne idée, effectivement. Mais quelle sera l'interface publique de TApplication? En fait ce que je me demande c'est si c'est cette classe qui va gérer (dans le sens de "posséder": être responsable du cycle de vie) la(les?) fenêtre(s?) et les contrôles?

    Et heu... pourquoi avez-vous choisi le T en préfixe (TMyClass)? C'est que ça me rappelle de mauvais souvenirs de la VCL (je déteste les IDE de Borland - je ne dis pas qu'ils sont mauvais, juste que je ne les aime pas)
    Tester c'est douter, corriger c'est abdiquer.

  3. #23
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    Citation Envoyé par r0d Voir le message
    Ok, ton point de vue me convient
    Je ne connais pas boost.signal, je vais aller y jeter un coup d'oeil tout de suite pour m'assurer que c'est bien ce que je crois.
    Si j'en ai moi-même bien compris le fonctionnement, ce sera le cas

    Sois seulement attentif au fait qu'il y a deux boost.signals: la première version est non threadsafe, la seconde (boost.signals2) étant l'évolution thread safe de la première

    Je préconise d'utiliser cette dernière
    Une classe Application me semble une bonne idée, effectivement. Mais quelle sera l'interface publique de TApplication? En fait ce que je me demande c'est si c'est cette classe qui va gérer (dans le sens de "posséder": être responsable du cycle de vie) la(les?) fenêtre(s?) et les contrôles?
    En gros, les (seules ) fonctions qu'elle exposerait serait... int run() et sa surcharge int run(int argc, char* argv[]) (boost.options inside ) et un signal onQuitQuery (ou similaire) permettant de mettre fin à la boucle.

    Son (ses) princial / principaux membres "visuel(s)" serai(en)t... une TMainWindow ou ses spécialisations / dérivées.

    Il serait éventuellement possible de spécialiser / dériver TApplication de manière à y rajouter des objets "externes" (ex: des infos de connexion à une base de données , infos de thread principal ), à moins que l'on ne considère plus opportun de les placer dans la fenêtre principale (c'est le genre de chose qui mérite réflexion )

    Ce serait plutôt la fenêtre principale qui aurait la responsabilité de la durée de vie des autres éléments visuels

    Je ne fais ici que tracer un tableau rapide de ce que je voudrais, en réfléchissant "à voix haute", car rien n'a encore été décidé sur ce point

    Si donc vous avez des remarques à faire sur le sujet, n'hésitez pas (mais créez peut être une autre discussion, pour éviter de surcharger celle-ci )

    Et heu... pourquoi avez-vous choisi le T en préfixe (TMyClass)? C'est que ça me rappelle de mauvais souvenirs de la VCL (je déteste les IDE de Borland - je ne dis pas qu'ils sont mauvais, juste que je ne les aime pas)
    Pour respecter les règles de codage, et plus particulièrement les conventions de nommages

    Plus sérieusement, le fait est qu'une très grosse partie du travail va consister en la définition d'une série de modèles de classes, de politiques et de traits associés...

    Une personne ayant un bagage raisonnable en C++ sera donc sans doute très attiré par le fait de pouvoir effectuer un "fine tuning" des différentes classes, en mettant (pourquoi pas ) ses propres politiques / traits au points, ou en choisissant ceux et celles qui lui conviennent le mieux parmi l'existant.

    Par contre, le pauvre Jean (dans mon scénario N°1) sera tout à fait largué si on lui met une bibliothèque qui fonctionne uniquement à coup de spécialisations de template entre les pattes.

    L'idée sera donc de fournir une sélection utile et variée de tyedef sympa lui permettant... de travailler correctement.

    Ces typedef n'auront plus le préfixe T, et il sera donc "facile" de lui dire "attention, les classes préfixées, c'est "touche pas à ca p'tit con" "
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #24
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    10 031
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 10 031
    Points : 13 967
    Points
    13 967
    Par défaut
    Citation Envoyé par koala01 Voir le message
    la première version est non threadsafe, la seconde (boost.signals2) étant l'évolution thread safe de la première
    Attention à ce que l'on entend par là.

    "attention, les classes préfixées, c'est "touche pas à ca p'tit con" "
    c'est pas
    casse toi pauv' con
    ou
    fait pas le malin
    ?

  5. #25
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    Peut-être

    En tout cas, c'est un drapeau de danger à agiter devant n'importe quel zoulou qui n'est pas habitué à manipuler les templates
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #26
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    Citation Envoyé par yan Voir le message
    Attention à ce que l'on entend par là.
    Je vais donc préciser: c'est la version qui est susceptible d'être thread safe (qui dispose en tout cas de tout ce qu'il faut pour l'être en cas de besoin)
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  7. #27
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    4 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : août 2004
    Messages : 4 261
    Points : 6 667
    Points
    6 667
    Billets dans le blog
    2
    Par défaut
    Ha ok, T c'est pour Template. Bien

    Citation Envoyé par koala
    Son (ses) princial / principaux membres "visuel(s)" serai(en)t... une TMainWindow ou ses spécialisations / dérivées.
    Mouaich. Agrégation quand tu nous tiens... je n'aime pas trop cette idée de TApplication qui possède une TMainWindow (je pense d'ailleurs qu'il n'en faudrait pas qu'une), qui elle-même possède des contrôles. C'est rigide et ça peut poser des problèmes de maintenance.

    Mais d'un autre côté je ne sais pas trop comment faire autrement.
    Peut-être une factory qui nous permet de créer des fenêtres "à la volée", et après l'utilisateur gère lui même ses fenêtres... je sais pas...

    edit: en fait la question est: "a-t-on besoin d'un lien fort entre la classe TApplication et les fenêtres?"
    Tester c'est douter, corriger c'est abdiquer.

  8. #28
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    Citation Envoyé par r0d Voir le message
    Ha ok, T c'est pour Template. Bien
    C'est... logique

    Mouaich. Agrégation quand tu nous tiens... je n'aime pas trop cette idée de TApplication qui possède une TMainWindow (je pense d'ailleurs qu'il n'en faudrait pas qu'une), qui elle-même possède des contrôles. C'est rigide et ça peut poser des problèmes de maintenance.
    Cela peut poser des problèmes de maintenance, mais d'un autre coté, si, justement, il y a plusieurs fenêtre pouvant être considérées comme principales, il sera sans doute plus facile de faire dériver une classe Application pour y rajouter les fenêtres supplémentaires que de devoir commencer à gérer une collection de fenêtre à la main (d'autant plus que, les template aidant, nous risquons de ne pas avoir de base commune utile)

    En plus, cela permet de distinguer clairement les responsabilités: les éléments visuels (fenêtre en tête) sont dédiés à... la gestion des éléments visuels (ou de l'aspect "vue" du MVC) et l'application est dédiée à la gestion de "ce qui vient en plus" de l'aspect purement visuel.
    Mais d'un autre côté je ne sais pas trop comment faire autrement.
    moi non plus
    Peut-être une factory qui nous permet de créer des fenêtres "à la volée", et après l'utilisateur gère lui même ses fenêtres... je sais pas...
    Cela pourrait parfaitement être une des politiques mises en oeuvre, par exemple, lorsque nous nous attèlerons à l'évolution prévue qui consiste à permettre les déclarative ui
    edit: en fait la question est: "a-t-on besoin d'un lien fort entre la classe TApplication et les fenêtres?"
    Ma réponse est relativement simple: le lien doit être le plus faible possible, en dehors du fait que l'arrêt de l'application doit signifier... la destruction de la fenêtre

    C'est pour cela que j'envisage les classes Application et MainWindow (ou similaire) sous la forme de modèles et que je souhaite séparer clairement les deux

    Il ne faut pas oublier qu'à terme, tu aura des fenêtres 2D ou 3D, des applications multi-threadées ou non, qu'il sera souhaitable d'avoir plusieurs "fenêtres principales", ou d'avoir une fenêtre principale "éclatée", un peu à la manière de ce que fait the Gimp, que l'application devra pouvoir gérer des timers ou des connexions divers et variés ou que sais-je.

    Seule une séparation claire de l'application en elle-même par rapport à la (les) fenêtre(s) principale(s) nous permettra une telle souplesse dans l'utilisation
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  9. #29
    r0d
    r0d est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    4 261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : août 2004
    Messages : 4 261
    Points : 6 667
    Points
    6 667
    Billets dans le blog
    2
    Par défaut
    Ok. Bon on peut partir là-dessus pour l'instant, et si on parvient à ce que le lien entre l'application et les fenêtres reste ténu, ce sera simple de les séparer si besoin est.


    "And now something diferent"


    Un des objectifs de cette lib est d'être utilisable facilement par des débutants, mais de permettre également de faire des choses très complexes. En lisant la discussion d'à côté, il m'est apparu tout de suite l'idée de faire deux couches: une couche très modulaire, avec des templates dans tous les sens, et une couche au-dessus qui spécialisera celle-ci. C'est par exemple ce que fait la STL avec la classe string qui spécialise basic_string avec les politiques et allocateur qui va bien. Voyez-vous ce que je veux dire? (l'idée étant de ne pas faire des parties distinctes selon l'utilisateur cible, mais juste des couches superposées).
    Tester c'est douter, corriger c'est abdiquer.

  10. #30
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 578
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 578
    Points : 30 376
    Points
    30 376
    Par défaut
    C'est en tout cas ainsi que j'envisage les choses...

    nous avons une couche extrêmement flexible, à base de template, que peuvent utiliser les programmeurs "pointus" et, au dessus, une couche basée sur la spécialisation à coup de typedef, commençant au niveau de "Point2D" et s'étendant jusqu'à "ApplicationMultiThread" qui permet d'utiliser Button, Menu, MenuItems, etc, et qui est accessible "à tous"
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Discussions similaires

  1. [Séparer son code] quelques petites questions.
    Par echantillon dans le forum C
    Réponses: 33
    Dernier message: 07/03/2007, 17h29
  2. quelques petites questions
    Par la debutante dans le forum Windows
    Réponses: 1
    Dernier message: 20/12/2006, 09h08
  3. quelques petites questions sur les windows form
    Par natasha84 dans le forum C++/CLI
    Réponses: 22
    Dernier message: 25/05/2006, 22h14
  4. Quelques petites questions sur le shell
    Par Badaboumpanpan dans le forum Linux
    Réponses: 8
    Dernier message: 01/04/2006, 00h09
  5. [Tk] Quelques petites questions
    Par Damian dans le forum Interfaces Graphiques
    Réponses: 2
    Dernier message: 06/02/2006, 16h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo