Discussion :

[Luc Hermitte]

Bonjour,

Je suis en train d'évaluer/analyser un outil d'analyse statique de code, dans sa dernière version, il y a une nouvelle vérification d'une règle MISRA C++ qui en substance exige que toute fonction virtuelle définie ne doive jamais être re-définie -- à quelques exceptions près pour les destructeurs et pour les fonctions virtuelles pures qui ont des implémentations par défaut.

Je gamberge depuis deux jours sur le sujet, et j'ai du mal à me faire une idée entre:
- ça n'apporte pas grand chose
- ça introduit des complications qui vont nous brider
- c'est un vrai gros plus.

Dans tous les cas, je n'ai pas trouvé d'exemples qui allaient vraiment dans un sens ou dans l'autre.

En gros, cela nous interdit les classiques

Code :

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

1
2
3
4
5
6
7
struct Child : Super {
    virtual void f() {
        foo()
        Super::f();
        bar();
    }
};

et ce n'est pas un mal. Bien au contraire -- oui, je préfère le DP Template Method.

Mais cela complique aussi les choses pour définir des comportements par défaut qui pourraient être spécialisés dans des classes filles. Ce qui interdirait ce genre de chose (que j'utilise dans mes cours)

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
25
26
struct DataRenderer : noncopyable{
    virtual ~DataRenderer() {}
    void render(DataList const& dataList_) {
        do_prologue();
        for (auto const& data : dataList_) { do_render(data); }
        do_epilogue();
   }
private:
   virtual void do_prologue() {} // oui il y a une implémentation par défaut qui n'en fout pas une
   virtual void do_epilogue() {} // oui il y a une implémentation par défaut qui n'en fout pas une
   virtual void render(Data const& data_) = 0;
}
 
struct XMLDataRenderer : DataRenderer {
private:
   virtual void do_prologue() override { cout << "<datalist>"; } // je viole la règle
   virtual void do_epilogue() override { cout << "</datalist>";} // je viole la règle
   virtual void render(Data const& data_) override { ... }
};
 
struct GnuplotDataRenderer : DataRenderer {
private:
   // ici, je profite de l'implémentation par défaut du prologue et de l'épiloque
   // et il en ira de même pour des sorties .csv/.tsv/...
   virtual void render(Data const& data_) override { ... }
};

Est-ce vraiment hérétique d'être pragmatique en profitant de ce comportement par défaut ?

[jblecanard]

Hello

Est-ce vraiment hérétique d'être pragmatique en profitant de ce comportement par défaut ?

Pour ma part, à ceci je répond non. Le comportement par défaut est particulièrement utile pour écrire des adapters.

[Médinoc]

Cela ressemble beaucoup à "Seules les classes feuilles de la hiérarchie peuvent être concrètes".

[Luc Hermitte]

@Medinoc, cela adresse d'autres aspects orthogonaux.
Le fait que ma classe de base est abstraite est un détail : il pourrait y avoir une autre classe dérivée qui spécialise un comportement, mais qui reste abstraite.

Après, il est vrai que ce que tu énonces interdit de redéfinir une fonction qui a déjà été définie.

[white_tentacle]

Je vais seulement faire une remarque, mais pour l’instant je me garderai bien de porter un jugement définitif.

Code c++ :

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

1
2
3
4
5
6
7
8
 void render(DataList const& dataList_) {
        do_prologue();
        // corps de fonctnio
        do_epilogue();
   }
private:
   virtual void do_prologue() {} // oui il y a une implémentation par défaut qui n'en fout pas une
   virtual void do_epilogue() {} // oui il y a une implémentation par défaut qui n'en fout pas une

et

Code c++ :

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

1
2
3
4
5
6
7
8
 
struct Child : Super {
    virtual void f() {
        foo()
        Super::f();
        bar();
    }
};

C’est la même chose, à la différence près que dans le premier cas, on a intégré dès le départ que le corps de la fonction pouvait être précédé d’un prologue / suivi d’un épilogue, alors que dans le deuxième on a fait ça un peu à la rache.

[KsassPeuk]

Lu'!

Autant si je trouve que le premier cas évoqué est effectivement intéressant, le gain n'est pas assez grand pour justifier qu'on sacrifie le fait d'avoir plusieurs niveaux de variations pour les hiérarchies de classe. Le principal c'est surtout que la fonction membre implémentée respecte le contrat défini par la classe parente (et inductivement si c'est un membre dont elle hérite elle-même).

Après, quand on utilise le NVI pour vérifier ce genre de contrat, le problème c'est qu'à la première implémentation, on ne peut plus vérifier les contrats de nouvelles variations. Si on veut le faire, ça passe par un nouveau niveau de NVI. Donc on se retrouve dans le cas évoqué ici : une première variation définie est finale.

Après, j'suis pas un pro moi hein.