Discussion :

[DigitalGuru]

Bonjour à tous,
dans le cadre d'un projet de developpement assez conséquent, j'aurais besoin de créer une classe (un ensemble de classe en fait) qui représente un type variable.
L'UML doit donner à peu près :
http://img689.imageshack.us/i/variant.png/
De cette manière, j'ai une interface ultra générique qui joue le rôle d'une union mais sans avoir à faire de contrôle de type à chaque appel.

Est-ce possible ?
Merci d'avance !

[Lavock]

Variant pour moi, quelque part ça veux dire que le type va pouvoir changer en cours d'execution... Or là, non.

Il va falloir créer un FP pour la création de tes objets, et après, ben tu peux designer tout tes type par variant et les mettre dans une collection... Mais tu pourra en rien changer leur type.

A part ça, si cest pas se genre de variant, alors c'est OK !

[DigitalGuru]

DSL double post...

[Cheps]

Sinon il y a boost:variant, je l'ai jamais utilisé personnellement mais ça ressemble à ce dont tu as besoin.

[DigitalGuru]

Je me suis mal exprimé en effet. Le type ne changera pas à l'exécution. Il sera fixe.
Le but recherché est de pouvoir créer une méthode du type GetResult dans une classe abstraite qui retourne un type différent selon la classe qui dérive l'abstract.

J'ai un peu de mal a m'expliquer, par exemple :

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
 
void UneMéthode(Variant* V){
    cout << "Voici le contenue de ma variable :" << V->GetResult() << endl;
}
 
int main(int argc, char** argv){
    Variant* V = new VInt(5);
    Variant* V2 = new VString("Hello World !");
 
    UneMéthode(V);
    UneMéthode(V2);
 
    delete V;
    delete V2;
 
    return 0;
}

Est-ce plus clair ?

[koala01]

Salut,

Le premier conseil que j'aurais tendance à te poser, c'est de savoir s'il est vraiment opportun de faire en sorte de pouvoir mélanger les différents types qui dérivent de Variant (selon ton schéma) dans une collection d'objets...

Même en passant sur le fait que, quelque part, je ne suis pas du tout persuadé qu'il soit opportun de disposer d'office d'un accesseur et d'un mutateur, je me demande réellement s'il est opportun de vouloir:

• encapsuler les types primitifs en leur laissant leur sémantique de valeur
• être en mesure de créer un tableau (par exemple) dont le premier élément est un entier, le second un réel et le troisième, pourquoi pas, une chaine de caractères (par exemple, toujours)
• Etre en mesure de récupérer une chaine de caractères au départ d'un entier ou d'un réel (cela peut se comprendre) mais, pire, être en mesure de récupérer un entier ou un réel au départ d'une chaine de caractères qui risque... de ne pas représenter une valeur numérique...

Si, vraiment, tu es face à une situation dans laquelle il est opportun de le faire, peut être devrais tu te tourner vers boost variant.

Mais si l'idée est, simplement, de t'éviter de devoir recréer l'interface, peut-être te fais tu beaucoup de mal pour pas grand chose

Au pire, si, vraiment, ce n'est que pour l'interface, mais qu'il n'est pas vraiment nécessaire de mélanger les différents types réels dans une même collection, tu peux, peut-être, envisager l'utilisation des template sous une forme qui serait proche 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
21
22
23
24
template <typename T>
class TValueHolder
{
    public:
        typedef T type;
        typedef T const & constref;
        constref  value() const{return v_;}
        void set(constref v){v_=v;}
    protected:
        /* cette interface doit, d'office, être héritée ... */
        TValueHolder(constref v):v_(v){}
        ~TValueHolder(){};
    private:
        type v_;
};
class ValueInt : public TValueHolder<int>
{
    /*autres fonctions et méhtodes adaptées */
};
class ValueDouble : public TValueHolder<double>
{
    /*autres fonctions et méhtodes adaptées */
};
/*...*/

mais il faut alors être conscient du fait que TValueHolder<int> et TValueHolder<double> représentent deux types différents, et qu'il est donc impossible d'envisager de les placer dans une collection commune

[Lavock]

Cela s'appelle les retour covariant si je ne m'abuse... Mais j'ai pas encore tout à fait compris ou tu veux en venir. Ton exemple est bizarre : tu pousse une erreur de compilation au runtime.
C'est dangereusement inutile si les type créer ne sont pas décider au runtime...

[DigitalGuru]

J'avais bien sûr pensé au templates mais le souci c'estr justement que les types peuvent être mélangés (dans une colleciton par exemple).

Mon projet consiste en un framework de node compositing (Cf Node Compositing de Blender par exemple). Un système de boîtes concretement ayant n entrées et m sorties, celles-ci pouvant être d'un type différent.
L'intérêt pour moi est de ne pas avoir à manier des void* (ou des Boost::any ou Boost::variant) et par conséquent à caster à tout bout de champs.

[Lavock]

Donc oui, c'est faisable... Mais encore une fois, là ou des bug pourrait être intercepté dès la compilation, tu vas devoir y faire face au runtime.
Je ne serai conseillé ce genre d'approche.

[DigitalGuru]

Comment faire alors ?

[Lavock]

Attent deux secondes... Tes "entrées" sont des type primaire ? Hum....

Ben va falloir que tu te refarcisses tous les types pour les maniées comme des PODs... avec une couche java-like.

Ou alors, mieux, utiliser "..." (stdarg.h).

[edit]
En faite, je comprend vraiment pas ou tu veux en venir... Pourquoi ne pas faire plutôt juste << v ou encore v.write dans ton exemple au dessus.

Qu'est-ce que tu as maintenant, que veux tu avoir après ?

[DigitalGuru]

Je crois que je vais finalement utiliser des templates "basiques" mais encapsulés de manière a pouvoir gérer des collections.
J'en profiterai pour regarder les boost::any et variant.

Merci de votre aide, à bientôt !

[3DArchi]

Je crois que je vais finalement utiliser des templates "basiques" mais encapsulés de manière a pouvoir gérer des collections.
J'en profiterai pour regarder les boost::any et variant.

Merci de votre aide, à bientôt !

Salut,
Jettes un coup d'oeil à ce tuto : Type Erasure, par Alp Mestan. J'ai l'impression que ça peut t'aider.
Sinon, en manipulant des types vraiment sans rapport, il est fortement probable qu'un downcast soit à un moment ou un autre nécessaire, soit explicitement soit implicitement dans un visiteur.

[koala01]

Ceci dit, je reste persuadé qu'il y a surement des propriété bien plus remarquables à factoriser que de simples accesseurs, ou pire, des mutateurs...

N'oublie pas que le grand principe de l'OO est... de réfléchir plutôt en terme de comportement...

Interroge toi peut etre sur les comportement que tu estimes devoir attendre de la part de tes différents objets, puis sur la possibilité qu'il peut y avoir à donner une implémentation par défaut pour ces différents comportements.

Si tu en arrive à la conclusion que tu dispose, dans la classe de base, des données permettant d'implémenter un comportement donné, implémente le directement dans la classe mère, quitte à le redéfinir pour certaines classes dérivées.

Si par contre, tu rencontre un comportement pour lequel il n'est pas cohérent de fournir une implémentation par défaut ou pour lequel tu ne dispose pas des informations nécessaires à son implémentation dans la classe de base (parce qu'il n'est pas cohérent de les y mettre), fais en une fonction virtuelle pure, et n'oublie pas de définir cette fonction dans toutes les classes concrètes dérivées