Discussion :

[oodini]

Bonjour,

Soit une hiérarchie de classes. Seules certaines d'entre elles seront directement instanciées (bien qu'elles soient pour l'instant toutes instanciables...).

Je voudrais que chacune des classes instanciables continne un vecteur de chaînes de caractères, dont le contenu est spécifique à cette classe, et commun à toutes ses instances. Ce qui nous amène donc à la déclarer statique.

Pour m'assurer de la présence de ce vecteur, je souhaitais donc le déclarer dans la classe parente, bien que seules certaines de ces classes dérivées vont remplir ce vecteur. Y a-t-il une méthode plus intelligente ?

Si je reste sur cette conception, comment puis-je initialiser le vecteur de manière statique ?

Merci.

[Florian Goo]

Bonjour,

Attention, si tu déclares le vecteur dans la classe parent, toutes les classes dérivées vont partager le même vecteur.

Pour initialiser un vecteur déclaré en static, tu peux appeler une fonction renvoyant un vecteur initialisé comme tu le souhaites :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
std::vector<int> vector_initializer()
{
    std::vector<int> v;
    v.push_back(1);
    v.push_back(2);
    //…
    return v;
}
 
std::vector<int> my_class::my_vector = vector_initializer();

[oodini]

Merci pour l'astuce d'initialisation !

Mais y a-t-il un moyen de contraindre les classes instanciables à avoir un vecteur statique ?

Quelque chose comme les fonctions virtuelles pures, mais pour une donnée...

[Florian Goo]

Tout ce que tu peux faire, c'est forcer les classes dérivées à implémenter un accesseur (ou un getter) pour ce vecteur.
Étant donné qu'une donnée membre, même statique, doit de préférence (si ce n'est toujours) être privée (même pas protected), cela devrait suffire, non ?

[oodini]

OK, je vais faire comme ça.

Merci.

[oodini]

Ce qui est dommage, c'est que le contenu de la fonction en question est identique quelle que soit la classe, mais que je ne peux la factoriser, parce qu'elle fait appel à une donnée statique qui n'est définie que plus bas dans la hiérarchie... :-/

[Florian Goo]

Eh oui, on ne peut pas toujours tout factoriser !

Cela dit, tu peux utiliser le préprocesseur. C'est ce que je fais dans ces cas là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#define SOCOA_CPP_DEFINE_VISITABLE()    \
    void                                \
    accept(visitor& a_visitor) const    \
    {                                   \
        a_visitor.visit(*this);         \
    }

Pense à bien préfixer le nom de ta macro avec quelque chose d'unique, comme par exemple le namespace de tes classes (dans le cas du dessus, le namespace est socoa::cpp). Il faut toujours utiliser le préprocesseur avec beaucoup de précautions.

[oodini]

Je trouve que tout cela complexifie pas mal code. Ça me chagrine un peu.

Je vais peut-être abandonner le statique, quitte à dupliquer des données. Après tout, ce n'est jamais qu'un vecteur d'une demi-douzaine de chaînes de moins de 10 caractères. Et comme c'est utilisé dans un algo déjà bien alambiqué...

Bref, je me tâte....

[Florian Goo]

Je pense qu'il est toujours possible d'allier lisibilité et performances. Si tu choisis des noms de classes/fonctions/macros explicites avec une bonne convention de nommage, ça tient la route.

Et dans ton cas, le code est compliqué mais les retombées sur les performances sont nulles vu que tout est préprocessé et inliné.

[oodini]

Je vais faire autrement.

J'ai la chance de disposer d'une association [type <-> chaîne de caractères].

Je vais donc mettre dans ma classe parente une structure de données statique, constituée d'un
map< string, vector<string> >
Je définirai dans ma classe parente une méthode qui prend en paramètre le nom du type, et chaque classe dérivée appellera cette fonction avec comme paramètres le nom du type et la chaîne à rechercher dans le vecteur.

Simple et efficace. :-)

[koala01]

Salut,

Selon moi, le plus cohérent serait - outre la possibilité d'avoir la classe de base sous forme de template qui pourra être abordée plus tard - de déclarer une méthode virtuelle pure "init()" (par exemple) dans la classe de base (en n'oubliant pas que, du coup, la classe de base devient abstraite) et de déclarer le vecteur statique dans... les classes dérivées.

Pour chacune des classes dérivées, "YAPUKA" réécrire, finalement, le même code, en l'adaptant aux valeurs à insérer en fonction de la classe imbriquée sous une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
void Derivee::init()
{
    if(tab.empty())
    {
        tab.push_back("chaine1");
        tab.push_back("chaine2");
        tab.push_back("chaine3");
        tab.push_back("chaine4");
        /* ... */
    }
}

L'idée reste identique pour la récupération et la recherche des valeurs contenues dans le vecteur

[JolyLoic]

outre la possibilité d'avoir la classe de base sous forme de template qui pourra être abordée plus tard -

Tu penses à un truc genre CRTP ? genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class Base {};
template<class T>class Intermediate : public Base {static vector<string> v;};
class Derivee1 : public Intermediate<Derivee1> {}

[koala01]

Tu penses à un truc genre CRTP ? genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class Base {};
template<class T>class Intermediate : public Base {static vector<string> v;};
class Derivee1 : public Intermediate<Derivee1> {}

Exactement, ou, du moins, basé dessus...

On pourrait séparer les responsabilités, et donc avoir d'un coté, une interface template responsable de la gestion du vecteur (avec les comportements adaptés), de l'autre une classe de base regroupant les autres comportements cohérents, et, au final, les classes instanciables héritant de l'interface (CRTP) et de la classe de base
En spécialisant le constructeur de l'interface pour chaque type dérivé, il devrait être possible que tout se fasse tout à fait naturellement, et de manière transparente pour l'utilisateur de la classe instanciable

[oodini]

Selon moi, le plus cohérent serait - outre la possibilité d'avoir la classe de base sous forme de template qui pourra être abordée plus tard - de déclarer une méthode virtuelle pure "init()" (par exemple) dans la classe de base (en n'oubliant pas que, du coup, la classe de base devient abstraite) et de déclarer le vecteur statique dans... les classes dérivées.

Mais où est déclaré ton tab ?
Si c'est dans le parent, toutes les classes dérivées profiteront de l'ajout des membres au vecteur.
Si c'est dans la classe dérivée, je devrais copier en "local" le vecteur statique de la classe parent.

[koala01]

Ah, je n'avais pas compris qu'il y avait une base commune au contenu du tableau de chaque élément...

Dés lors, ce que l'on peut envisager, c'est d'avoir un tableau statique dans la classe mere et un tableau statique dans la classe fille (d'un autre nom), et de comparer la taille du tableau de la classe fille avec le nombre d'éléments contenu par le tableau de la classe mère dans la méthode nommée init...

Si le nombre d'éléments du tableau de la classe fille est 0, on copie les éléments du tableau de la classe mère, puis on ajoute ceux qui sont propres à la classe fille.

Si le nombre d'éléments du tableau de la classe fille est strictement identique à celui du tableau de la classe mère (ce qui ne devrait normalement jamais arriver), on ajoute dans le tableau de la classe fille les éléments qui lui sont propres

Si, enfin, le nombre d'éléments du tableau de la classe fille est supérieur à celui du tableau de la classe mère, c'est que le tableau a déjà été correctement initialisé, et qu'il n'y a plus rien à faire