Méthodes virtuelles C++ pour les attributs propres à la classe ou la structure externe

Question

J'ai un ensemble de classes dérivées toutes d'une classe de base commune. Je veux utiliser ces classes de manière polymorphique. L'interface définit un ensemble de méthodes getter dont les valeurs de retour sont constantes dans une classe dérivée donnée, mais varient d'une classe dérivée à l'autre. .: par exemple

enum AVal 
{ 
    A_VAL_ONE, 
    A_VAL_TWO, 
    A_VAL_THREE 
}; 

enum BVal 
{ 
    B_VAL_ONE, 
    B_VAL_TWO, 
    B_VAL_THREE 
}; 

class Base 
{ 
    //... 
    virtual AVal getAVal() const = 0; 
    virtual BVal getBVal() const = 0; 
    //... 
}; 

class One : public Base 
{ 
    //... 
    AVal getAVal() const { return A_VAL_ONE }; 
    BVal getBVal() const { return B_VAL_ONE }; 
    //... 
}; 

class Two : public Base 
{ 
    //... 
    AVal getAVal() const { return A_VAL_TWO }; 
    BVal getBVal() const { return B_VAL_TWO }; 
    //... 
}; 

etc.

Est-ce une façon courante de faire les choses? Si la performance est un facteur important, serais-je mieux tirer les attributs dehors dans une structure externe, par exemple .:

struct Vals 
{ 
    AVal a_val; 
    VBal b_val; 
}; 

stocker une Vals* dans chaque cas, et la réécriture Base comme suit?

class Base 
{ 
    //... 
    public: 
    AVal getAVal() const { return _vals->a_val; }; 
    BVal getBVal() const { return _vals->b_val; }; 
    //... 
    private: 
    Vals* _vals; 
}; 

La déréférence supplémentaire est-elle essentiellement la même que celle de vtable? Quel est l'idiome établi pour ce type de situation? Sont à la fois de ces solutions stupide? Tous les aperçus sont grandement appréciés

Answer 1

La première méthode semble plus claire et vous oblige à remplacer ces méthodes (au premier enfant de toute façon). Je pense que les frais généraux des appels virtuels ont tendance à être inférieurs à ce que l'on pourrait attendre. Seulement si vous profilez le code et que les appels virtuels prennent beaucoup de temps, j'essaierais de faire des optimisations comme dans votre seconde approche. Cela dit, quel problème tentez-vous de résoudre? Parfois, les identifiants de classe comme celui-ci sont utiles, mais parfois une abstraction d'interface différente peut accomplir la même chose sans avoir une telle interface du tout.

Answer 2

Personnellement, j'implémenterais une sorte de, GetTypeStats(), qui renvoie une structure (référence à) qui contient toutes les informations spécifiques dérivées, ou une interface de requête comme dans D3D. Vous devriez également considérer le polymorphisme statique dans ce scénario. Cependant, si vos classes DOIVENT être polymorphes à l'exécution, alors vous ne pouvez rien faire pour éliminer les appels de fonction virtuelle.

Answer 3

Si tout ce qui diffère sont les valeurs et ils sont fixés à la compilation, vous pouvez les faire arguments de modèle:

template< AVal aval, BVal bval> 
class Derived : public Base 
{ 
    AVal getAVal() const { return aval }; 
    BVal getBVal() const { return bval }; 
}; 

typedef Derived<A_VAL_ONE, B_VAL_ONE> One; 
typedef Derived<A_VAL_TWO, B_VAL_TWO> Two; 

Answer 4

C'est une façon courante de faire un pauvre homme de dynamic_cast pour les types polymorphes, lorsque le programmeur veut éviter l'utilisation de dynamic_cast. Dans ces cas, il s'agit d'une micro-optimisation. Comme avec toutes les micro-optimisations, vous devez utiliser un jugement basé sur besoin avant d'aller de l'avant avec elle. Si le profileur vous dit qu'il n'y a aucun gain de performance à faire ceci plutôt que dynamic_cast, vous seriez probablement beaucoup mieux en utilisant simplement dynamic_cast.