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

C++ Discussion :

classe de collection de paramètre dérivable.


Sujet :

C++

  1. #1
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut classe de collection de paramètre dérivable.
    Bonjour,

    Dans le cadre d'un petit projet contenant notamment des clases de widgets affichables à l'écran, je cherche un moyen élégant de fournir une liste de paramètres à mes classes de widget (par exemple un bouton, un label de texte, ...).

    L'idée est qu'un widget peut prendre un nombre important de paramètres, tous optionnels, et qu'on veut pouvoir spécifier dans un ordre quelconque. Or dans ce cadre un constructeur 'classique' est inapproprié:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    class Button {
        Button(Coord pos, int width, int height, Color c, float alpha a, SizePolicy policy, float textSize, Color focusColor, Color selectedColor, (void)(*fn) clickedCallback, /* etc... */);
    };
    En effet, la plupart du temps l'immense majorité des propriétés utilisées sont celles par dafaut.

    D'où l'idée d'avoir un constructeur capable de recevoir une liste de propriétés et qui ira piocher dans ses propriétés par défaut pour celles non spécifiées, le tout avec une syntaxte la plus légère possible. Quelque chose du genre:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    class Button {
        Buton(ParamSet& params) {
            _color = params.getOrDefault<ColorParam>( /*defaultValue*/ Color::WHITE);
        }
    };
    L'instanciation se faisant avec quelque chose comme:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    btn = new Button( params<<ColorParam(Color::BLUE)<<PosParam(12,34) );
    J'ai donc commencé une petite classe abstraite générique qui permet d'avoir un type de base unique (pour être ensuite stocké dans une collection):
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    class IParam {
    };
    Puis une classe dérivée, template, capable de contenir un paramètre 'simple' avec son type associé:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    template <typename PARAMTYPE>
    class SingleParam : public IParam {
    public:
    	SingleParam(PARAMTYPE p) : value(p) {}
    	virtual PARAMTYPE get() { return value; }
    	PARAMTYPE value;
    	typedef PARAMTYPE ParamValueType;
    };
    (on notera la déclaration du typedef pour lier le type de la valeur sotckée par ce paramètre en fonction de la classe de paramètre)


    Et une classe concrètement utilisable un 'AlphaParam' qui stocke ici un float:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    class AlphaParam : public SingleParam<float> {
    public: 
        AlphaParam(float a) : SingleParam(a) {} 
    };

    On continue avec la création d'une classe abstraite pour contenir une liste de paramètres:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    class IParamSet {
    public:
    	virtual ~IParamSet() {}
    };
    Et sa classe dérivée basée sur des méthode getter/setter templates:
    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
     
    class ParamSet : public IParamSet{
    public:
    	virtual ~ParamSet() { /* ... */ }
    	template <typename PARAMCLASS> typename PARAMCLASS::ParamValueType get() {
    		for (list<IParam*>::iterator it = params.begin() ; it != params.end() ; ++it) {
    			IParam* iparam = *(it);
    			PARAMCLASS* param = dynamic_cast<PARAMCLASS*>(iparam);
    			if (param) {
    				return param->get();
    			}
    		}
    		throw Exception("param not found.");
    	}
    	template <typename PARAMCLASS> void add(typename PARAMCLASS::ParamValueType paramvalue) {
    		IParam* p = static_cast<IParam*>(new PARAMCLASS(paramvalue));
    		params.push_back(p);
    	}
    	list<IParam*> params;
    };
    A ce niveau, tout va bien puisque l'utilisateur de ces classes peut s'en servir de la façon suivante:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
            // création et population d'un ParamSet
    	ParamSet paramset;
    	paramset.add<AlphaParam>(0.5f );
     
            // récupération d'une propriété d'un paramSet
    	float alpha = paramset.get<AlphaParam>();
    Jusque là tout va bien.

    Mais ma classe IParam doit pouvoir prendre plusieurs formes car le projet a vocation à propsoer un binding Javascript des classes widget. Et donc proposer en plus d'une API 'sympa' pour les codeurs C++, une API 'tout aussi sympa' pour ceux qui coderont en Javascript.

    Dans le cas d'une instanciation depuis le Javascript, le binding recevra un unique paramètre de type 'objet JS', soit l'équivalent d'un JSON. Exemple:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    myJsButton = new JsButton( {
        pos:[100,200],
        color: [255,255,255],
        alpha: 0.5,
        onClickedFn: myOtherFunction
    } );
    L'idée est donc d'avoir une seconde class dérivée de IParam dont l'implémentation dérivant de IParam capable d'extraire les paramètres à partir de l'objet JSON venant du monde Javascript:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    class JSParamSet {
        JSParamSet(JSObject o) : data(o) { /* ... */ }
        template <typename PARAMCLASS> typename PARAMCLASS::ParamValueType get() {
            return JSObjToNativeParam<PARAMCLASS>(data);
        }
        JSObject data;        
    };
    (.. avec une fonction JSObjToNativeParam qui se charge d'extraire le pramètre de l'instance de de JSObject via une spécialisation de template).


    D'où une utilisation dans ma classe Button à partir du type abstrait IParam
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    class Button(IParam& params) { _alpha = params.get<AlphaParam>(); }

    Problème: il m'est évidemment impossible de dériver des méthodes templates d'une classe de base commune. Donc impossible de faire une sorte de classe IParam qui proposerait à ma classe Button des méthodes template comme 'get<paramtype>' ou 'getOrDefault<paramtype>' destinées à être surchargées dans des implémentations visant des utilisations distinctes (natif, js, ...).

    Une idée pour m'en sortir ?

    A noter que je suis assez ouvert à toute proposition, même peut optimum en termes de performances (on n'instancie pas 100 000 boutons par seconde). Le principal étant que:

    - le codeur C++ ait un moyen de déclarer ses paramètres directement dans l'appel au constructeur de la classe widget, avec la syntaxte la plus concise possible.

    - le code JS ait une API qui se base sur le passage en paramètre d'un unique objet JS (JSON like) pour faire la même chose.


    Merci d'avance
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  2. #2
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Points : 15 620
    Points
    15 620
    Par défaut
    Salut



    Ça me parait violent comme solution juste pour une question de sucre syntaxique. Architecture lourde à base de god object...

    Ce que tu veux faire en fait, c'est du named parameter et chaining method (cf FAQ et wiki), non ?

    En gros, ça permet d'écrire quelque chose comme ça :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    btn = Button().Color(Color::BLUE).Pos(12,34);
    Et la conversion en script est rapide aussi
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    myJsButton = new JsButton( {
        pos:[100,200],
        color: [255,255,255],
        alpha: 0.5,
        onClickedFn: myOtherFunction
    } );
     
    // devient
     
    myJsButton = JsButton()
        .pos(100,200)
        .color(255,255,255)
        .alpha(0.5)
        .onClickedFn(myOtherFunction);
    Ca répond pas à tes besoins ?

  3. #3
    Invité
    Invité(e)
    Par défaut
    slt,

    - le codeur C++ ait un moyen de déclarer ses paramètres directement dans l'appel au constructeur de la classe widget, avec la syntaxte la plus concise possible.
    pourquoi pas utiliser une serialisation?

    quelquechose genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    Buton(ParamSet()<<monInt(22)<<monString(12));
    Button(ParamSet& p){
     if(p.contains(monInt.getKey())){
      monInt _monInt;
      p.deserialize()>>_monInt;
     }
    }
    avec par exemple la serialization d'un Parameter qui est faite du genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    std::stringstream s
    s<<TOKEN_KEY_BEGIN;
    s<<monInt.getKey();
    s<<TOKEN_KEY_END;
    s<<monInt.getSerializedContent()
    puis apres tu captures les cles de la string et si present tu appeles le deserialize (qui saura ou deserialiser grace a sa cle!)

    le binding json c'est la meme chose, juste faut adapter la deserialisation de tes objets, ainsi que la recherche de la cle dans ta json string

  4. #4
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Hello,

    et tout d'abord merci pour vos réponses.

    Citation Envoyé par gbdivers Voir le message
    Ça me parait violent comme solution juste pour une question de sucre syntaxique. Architecture lourde à base de god object...
    Oui, c'est relativement 'violent', mais l'idée est que ça me convient si ça l'est pour le développeur de la lib tant que ça aboutit à quelque chose de limpide pour celui qui l'utilise.
    Si tu fais référence à la notion de performance, et comme brièvement évoqué dans mon post, c'est absolument pas critique. Ce mécanisme a vocation à être utilisé pour instancier de nouveau objets qui constituent autant d'éléments d'interface. C'est typiquement le genre de chose qu'on instancie une fois pour toute au lancement du programme et qu'on ne fait (quasiment) plus après. Donc perdre millisecondes d'horloge à ce moment là ne me gène nullement vis à vis de l'objectif de ma lib.

    Ce que tu veux faire en fait, c'est du named parameter et chaining method (...) Ca répond pas à tes besoins ?
    Oui, mais non. Je veux absolument partir sur un principe d'objet conteneur qui va héberger l'ensemble des paramètres plutôt que sur du chaînage d'appels à des méthodes de la classe juste instanciée. L'idée est que cette entité 'collection de paramètres' a vocation ensuite à pouvoir être réutilisée en tant que telle en dehors du strict contexte de l'instanciation de tel ou tel objet.

    Par exemple:

    - pouvoir faire une collection de paramètre qu'on définit une fois et qui est réutilisée comme 'thème' de l'ensemble des widgets qu'on instancie après

    - pouvoir proposer une forme (basique) de simili-héritage entre collections de paramètres

    - pouvoir faire une sorte l'introspection sur son contenu (par exemple pour un éditeur d'IHM.

    - pouvoir faire de la sérialisation / désérialisation.

    - etc...


    Citation Envoyé par galerien69 Voir le message
    pourquoi pas utiliser une serialisation?
    quelquechose genre Buton(ParamSet()<<monInt(22)<<monString(12));
    En fait je vais grosso modo mo'rienter vers quelque chose dans le genre, avec un peu de sucre syntaxique supplémentaire pour le C++ tout en gardant l'idée du json-like pour le côté JavaScript.

    Côté natif, il avec un template simple et une classe de base, je peux définir facilement des classes représentant un 'nom' de paramètre associé au type de la valeur qu'il contient:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    typedef IParamValue<float> Alpha;
    typedef IParamValue<Color> MainColor;
    typedef IParamValue<Color> BgColor;
    Avec un type de collection(qu'on va appeller Paramset) proposant une surcharge de l'opérateur 'virgule' et le casting d'un IParam en ParamSet, je pense pouvoir arriver à quelque chose qui serait utilisable avec un code comme celui-ci en C++ :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    Button* btn = new Button( (Pos(12,34), Alpha(0.5f), MainColor::BLUE, BgColor(1.f,0.5f,0.5f)) );
    (on note les parenthèse surnuméraires, indispensables pour que le compilo n'interprète pas les virgules comme des séprarteurs de paramètres du constructeur de Button)

    Et côté constructeur du widget, on a:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
     
    class Button : public IWdget {
    public:
        Button(ParamSet& params) : IWidget(params) {
            _bgColor = params.getOrDefault<BgColor>(Color::NONE);
            _mainColor = params.getOrDefault<MainColor>(Color::WHITE);
            _alpha = params.getOrDefault<Alpha>(0.0f);
        }
     
    private:
        Color _mainColor;
        Color _bgColor;
        float _alpha;
    };

    Pour l'implémentation je suis en train de voir pour un mix de collection de boost::any associé à quelques templates et l'utilisation de std::type_info pour l'aspect RTTI.

    J'essaierai de poster le détail de l'implémentation quand j'aurai quelque chose de propre.

    Cheers
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

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

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 614
    Points : 30 626
    Points
    30 626
    Par défaut
    Salut,
    Citation Envoyé par nouknouk Voir le message
    Oui, mais non. Je veux absolument partir sur un principe d'objet conteneur qui va héberger l'ensemble des paramètres plutôt que sur du chaînage d'appels à des méthodes de la classe juste instanciée. L'idée est que cette entité 'collection de paramètres' a vocation ensuite à pouvoir être réutilisée en tant que telle en dehors du strict contexte de l'instanciation de tel ou tel objet.

    Par exemple:

    - pouvoir faire une collection de paramètre qu'on définit une fois et qui est réutilisée comme 'thème' de l'ensemble des widgets qu'on instancie après

    - pouvoir proposer une forme (basique) de simili-héritage entre collections de paramètres

    - pouvoir faire une sorte l'introspection sur son contenu (par exemple pour un éditeur d'IHM.

    - pouvoir faire de la sérialisation / désérialisation.

    - etc...
    A vrai dire, je ne vois pas grand chose dans tout cela qui t'empêcherait d'utiliser la méthode proposée par gbdivers ...

    Rien ne t'empêche de définir (éventuellement par défaut) des valeurs considérées comme "non définies" dans tes paramètres nommés !!!

    Tu peux donc parfaitement fournir une liste exhaustive de paramètres qui correspond à l'ensemble de ceux que tu pourrais vouloir définir dans tes classes dérivées !!

    Une fois cela fait:
    - pouvoir faire une collection de paramètre qu'on définit une fois et qui est réutilisée comme 'thème' de l'ensemble des widgets qu'on instancie après
    ne pose aucun problème : ils se trouvent tous dans la structure
    - pouvoir proposer une forme (basique) de simili-héritage entre collections de paramètres
    Plus besoin, j'ai dit que tous les paramètres sont dans la structure
    - pouvoir faire une sorte l'introspection sur son contenu (par exemple pour un éditeur d'IHM.
    Rien de plus facile : vérifie pour chaque paramètre s'il représente une valeur connue comme étant indéfinie

    Le résultat de cette vérification te donnera, fatalement, la liste des paramètres utilisés
    - pouvoir faire de la sérialisation / désérialisation.
    Pas plus compliqué : c'est la structure de paramètres que tu sérialise quand tu sérialise ton widget (en ne prenant, pourquoi pas, que ceux qui présente une valeur "correcte" )

    Rajoutes, pourquoi pas, un accesseur sur chaque paramètres à la liste de paramètres, et pour le reste, bah, tu as deux possibilités:

    soit tu places la liste de paramètres dans l'accessibilité protégée de ta classe widget pour que toutes les classes dérivées puissent y accéder depuis leurs propres accesseurs / mutateurs, mais c'est peut etre la solution la plus crade;

    Soit tu places la liste de paramètres dans l'accessibilité privée de ta classe widget et tu implémente un pattern NVI pour chaque accesseur et mutateur.

    De toutes manières, il semblerait logique que ta classe widget propose l'ensemble des accesseurs et mutateurs proposés par tes classes dérivées, non

    Dés lors, tu pourrais donner, comme implémentation de base, le comportement réel d'accession / de modification, et, comme comportement redéfini le fait... de ne rien faire pour les paramètres que tes classes dérivées n'utilisent pas
    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. #6
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    (réponse courte, car depuis mon mobile)

    Le problème concernant la solution de tout mettre par défaut dedans concerne, je pense, l'extensibilité, puisque ça suppose de faire bouger le type à chaque ajout d'un nouveau type dérivé de (par exemple) IWidget, qui ajouterair ses propres paramètres.
    D'autant que ça me paraît à priori encore plus problématique quand on aborde le binding js (les classes pouvant être étendues côté c++ comme côté js).
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  7. #7
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Quitte à vouloir s'interfacer avec JS et à faire du JSON, autant faire les choses correctement et représenter ton JSON en mémoire, par exemple avec un code comme celui-ci.

    Ca t'évites la complexité d'héritage avec une super-classe et te permet d'utiliser tes ensembles de paramètres avec une sémantique de valeur, qui est la bonne sémantique pour un ensemble de paramètres à mon avis. Une solution à base de super-classe parente force une sémantique d'entité qui ne nous intéresse pas. C'est assez simple à maintenir en plus.
    Find me on github

  8. #8
    Modérateur
    Avatar de nouknouk
    Homme Profil pro
    Inscrit en
    Décembre 2006
    Messages
    1 655
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 1 655
    Points : 2 161
    Points
    2 161
    Par défaut
    Citation Envoyé par jblecanard Voir le message
    Quitte à vouloir s'interfacer avec JS et à faire du JSON, autant faire les choses correctement et représenter ton JSON en mémoire, par exemple avec un code comme celui-ci
    Oui, mais non, ce n'est pas du vrai JSON. J'ai évoqué avant tout le type 'objet JS', et pour simplifier le JSON parce que ça parle plus facilement à un développeur qui n'est pas rompu à l'utilisation de Javascript.

    Mais le binding se fait en ralité vers un 'objet' au sens Javascript, qui peut contenir d'autres données que des simples paramètres 'classiques'. Typiquement, la liste de paramètre pourra inclure des fonctions (ou callbacks, cf. mon premier post), des références vers d'autres instances de widget :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    var mainWidget = new Frame(/*...*/);
    
    var myClickedCallback= function() { 
        debug.write("my button is clicked !!!"); 
    };
    
    var myJsButton = new JsButton( {
        pos:[100,200],
        color: [255,255,255],
        alpha: 0.5,
        onClickedFn: myClickedCallback,
        parentWidget: mainWidget
    } );
    Mon projet du moment: BounceBox, un jeu multijoueurs sur Freebox, sur PC et depuis peu sur smartphone/tablette Android.

  9. #9
    Membre expert
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    1 415
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Mars 2007
    Messages : 1 415
    Points : 3 156
    Points
    3 156
    Par défaut
    Citation Envoyé par nouknouk Voir le message
    Oui, mais non, ce n'est pas du vrai JSON. J'ai évoqué avant tout le type 'objet JS', et pour simplifier le JSON parce que ça parle plus facilement à un développeur qui n'est pas rompu à l'utilisation de Javascript.
    Pas de souci, je suis rompu au Javascript.

    Je comprend ce que tu veux faire. Ne te trompe pas d'objectif. Il y a l'API que tu offres à tes devs et ce qu'il y a sous le capot. Tu ne pourras concevoir une structure qui est à la fois élégante pour un codeur C++ et adaptée pour prendre en charge le mapping en JS. Ce sont deux rôles différents.

    J'ai un peu l'impression que tu essayes de reconstruire une représentation C++ en mémoire d'un Object Literal de Javascript. Mais la runtime JS que tu vas prendre fait déjà cela ! Concentre toi plutôt sur les morceaux qui manquent.

    Pour moi, la bonne solution consisterait à :
    - Concevoir une structure en C++ qui permet au codeur C++ de configurer ses composants, à la C++ like.
    - Concevoir un module logiciel (classe ou ensemble de classes) qui se chargera de prendre ton objet JS depuis la runtime JS et qui fera les bons appels sur les composants C++ pour les configurer. Tu devras de toute façon écrire du code pour décrypter ta structure complexe en C++, donc autant l'écrire seulement là ou il est utile et où il a du sens.

    [Mode avis personnel subjectif sans connaissance des contraintes]A partir du moment ou tu comptes offrir une API JS pour la configuration de ton interface, je pense que tu ne devrais la configurer qu'en JS. Qui a envie de s'emmerder à configurer une interface graphique en C++ ? Ce n'est pas pour rien que tous les frameworks d'UI fournisse un langage dédié pour le faire (que ce soit XML, Python, JS ou autre).[/Mode avis personnel subjectif sans connaissance des contraintes]
    Find me on github

Discussions similaires

  1. Retrouver le type de class depuis uun type paramétré
    Par Asterius dans le forum Langage
    Réponses: 5
    Dernier message: 04/09/2008, 19h25
  2. Mapping collection et paramètre en plus
    Par rodbeck dans le forum Hibernate
    Réponses: 1
    Dernier message: 16/12/2007, 21h02
  3. exercices "classe et collections" vb
    Par aabdel dans le forum VB 6 et antérieur
    Réponses: 1
    Dernier message: 30/05/2007, 18h36
  4. Réponses: 1
    Dernier message: 21/02/2007, 10h57
  5. [Collection] type paramétré
    Par GLDavid dans le forum Langage
    Réponses: 4
    Dernier message: 12/06/2006, 11h03

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