Discussion :

[mister3957]

Bonjour à tous,

Je connais les méthodes virtuelles pure, mais par contre j'ai aucune idée de comment représenter l'inverse, à savoir, interdire la redéfinition d'une méthode.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class a
{
    void f();
}
 
class a2
{
    void f();
}

Comment générer un message du compilateur du style "La classe a a interdit de redéfinit la fonction f()"?

Merci,

A bientôt

[David Fleury]

souvent dans ces cas là, on demande : pourquoi faire ?

[dj.motte]

Salut,

Franchement je ne vois pas l'intérêt. A la limite on peut masquer une méthode dans une dérivation de classe, avec un truc un peu scabreux du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
class A
{
   public :
   void f() ;
};
 
class B : public A 
{  private :
    void f() ; 
    public:
 
};

Mais c'est pas terrible ...

[Luc Hermitte]

Si tu veux interdire la redéfinition (aka overriding, le truc qui supplante), il faut commencer par ne pas rendre la fonction virtuelle.
Ce qui n'empêchera pas la surcharge éventuellement masquante (si tu oublies le using)
Si tu veux interdire la surcharge, il te faudra interdire la dérivation.

Mais comme l'ont très bien dit dj.motte et Hylvénir: "je ne vois pas l'intérêt". C'est vrai quoi. "Pourquoi faire ?"

Il est vrai qu'il est bon de se protéger contre certaines erreurs d'étourderie (comme les copies incompatibles avec la sémantique, ou nos ressources), mais on ne peut pas tout contrôler. Si tes collègues/clients dérivent sans connaitre les tenants et aboutissants de la dérivation, tu n'y peux rien -- à part leur facturer une formation que tu vas leur donner.

[mister3957]

Ok, merci beaucoup,

A la base, c'est parceque je fais des exceptions qui dérivent d'une classe CException à moi. Chaque exceptions redéfinissaient la fonction What pour renvoyer le message.

Mais au fur et à mesure, la construction des messages de retour devenaient longue et contraignante et surtout, pour être homogène, il fallait faire en sorte d'avoir un affichage commun lorsque celui-ci intègre des causes possibles ainsi que plusieurs données nécessaires pour régler le problème.

Donc je me suis dit que ça serai pas mal, dans ma classe d'exception de base, de mettre un message qui serait par défaut dans les constructeurs des exceptions dérivées, et de proposer d'enrichir une liste de cause et une liste de paramètres.

Ainsi, au lieu de s'embêter à formatter un jolie message, on a juste à mettre un message de base, genre :

Code :

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

1
2
3
4
5
 
CFileAccessException e("Impossible d'accéder au fichier")
e.AddCause("Le fichier n'existe pas");
e.AddCause("Vous n'avez pas les droits d'y accéder");
e.AddParam("Fichier", m_sFilename);

Quant au message, c'est la fonction What() de la classe de base qui le formatterai avec le message en dur ainsi que les causes et les paramètres:

Impossible d'accéder au fichier.
Cause(s):
- Le fichier n'existe pas
- Vous n'avez pas les droits d'y accéder
Informations:
- Fichier : Config.ini

Alors principalement, c'était pour ne pas repasser toutes les exceptions pour retirer la méthode What(), mais bloquer la redéfinition dans la classe de base et me laisser guider par les erreurs du compilateur (car j'en ai un paquet d'exceptions).
C'est également pour éviter de faire des erreurs par la suite.

Merci beaucoup

[nicroman]

Ca m'étonnerai que l'IDE ne propose pas une fonction de refactoring adéquate pour ce genre de choses...

Sinon, Une idée... comme ça. J'imagine que ta fonction est "virtuelle" (sinon je vois pas trop ou est l'interêt), donc:
tu changes la valeur de retour de la fonction dans la classe de base, et tu vas récupérer un tas de warning (ou d'erreur, c'est selon) de compilateur te disant que la fonction n'a pas la même signature de retour dans telle ou telle class dérivée.

Au passage tu peux rendre aussi la méthode privée.