C++, désactiver une fonction de la classe de base

[jacknicklaus]

Bonjour,

ce code :

#include <iostream>

using namespace std ;

class Base
{
    public:
    virtual void  DoSomeThing(void)
    {cout << "accès interdit"; }
    
    void  DoSomeThingElse(void)
    { cout << "OK de la classe de base \n"; }
};

class Derived_1 : public Base
{
    public:
    virtual void  DoSomeThing(void)
    { cout << "OK de la classe dérivée 1 \n"; }
};

class Derived_2 : public Base
{
    public:
    virtual void  DoSomeThing(void)
    { cout << "OK de la classe dérivée 2 \n"; }
};

int main(void)
{

Base *B1 = new Derived_1;
B1->DoSomeThing();

Base *B2 = new Derived_2;
B2->DoSomeThing();

Base *B3 = new Base();
B3->DoSomeThingElse(); // <== ceci empêche de déclarer une virtuelle pure dans la classe de base

Base *B4 = new Base();
B4->DoSomeThing(); //<=== comment interdire ceci à la compilation ?
}

permet l'appel de la fonction "DoSomeThing" sur deux classes dérivées de la classe de base, à partir d'un pointeur sur la classe de base.

Je souhaite interdire l'accès à la fonction "DoSomeThing" depuis la classe de Base. Je le fais au runtime, comme le montre le code joint. Est-il possible d'interdire cet appel à la compilation ?

NB : il est impossible de passer par "DoSomeThing() = 0" car ceci interdirait l'instanciation de la classe de Base...


merci pour toute suggestion...
-----

[pm42]

Tu la mets protected plutôt que public dans la classe de base.

[jacknicklaus]

merci,

oui, mais non .


j'ai aussi des appels à DoSomething() depuis ailleurs que la classe de base et ses dérivées...

[pm42]

j'ai aussi des appels à DoSomething() depuis ailleurs que la classe de base et ses dérivées...

Ce que tu veux faire n'est pas très clair pour moi mais si j'ai bien compris, tu voudrais détecter la compilation le type réel sur lequel tu pointes pour autoriser ou non l'appel à une fonction ?
C'est totalement contradictoire avec le fonctionnement objet justement.

[A voir en vidéo sur Futura]

[umfred]

J'ai du mal à comprendre ta notion de interdire à la compilation son utilisation. si tu ne mets que sa déclaration dans la classe de base, si je ne dis pas de bétises, à la compilation ça va te générer une erreur (je dirais de type "fonction non implémenté")

Et tu dis aussi que tu l'appelles depuis ailleurs que la classe de base et ses dérivés, donc pourquoi elle serait dans la classe de base ?

[jacknicklaus]

en fait, mon problème est que j'appelle DoSomeThing sur indifféremment des objets de classe derived_1 ou derived_2, via un pointeur sur la classe de base.

Dans la logique de mon application, je n'ai jamais d'appel à DosomeThing sur un objet de la classe de base (qui existent pour d'autres besoins) mais je souhaite faire ceinture et bretelle et l'en empêcher, si une malencontreuse évolution de l'application devais survenir.
Mais pm42 a répondu, il est impossible de détecter celà autrement qu'au runtime. J'au donc implémenté la fonction DoSomething dans la classe de base simplement pour générer une erreur.

[pm42]

La logique voudrait que ta méthode soit pure virtuelle dans la classe de base mais tu dis que c'est impossible.

On doit être dans un des deux cas suivants :
- il faudrait revoir ta conception objet
- tu as touché les limites de la conception objet et de l'héritage qui ne permettent pas d'exprimer certains concepts facilement

Dans l'absolu, faire une méthode qui compile mais se plante à l'exécution est un grand classique présent dans des librairies réputées mais on qu'on devrait éviter autant que possible.

[jacknicklaus]

merci pour ces précisions. une dernière question dans la même ligne :

on connaît le mot clé "override" qui assure qu'une méthode d'une classe dérivée a bien une classe parent virtuelle avec une méthode de même nom et signature

existe t'il l'inverse ?

c'est à dire un moyen à la compilation de vérifier qu'une méthode virtuelle d'une classe parent a bien une classe enfant avec une méthode de même nom et signature ?

[pm42]

c'est à dire un moyen à la compilation de vérifier qu'une méthode virtuelle d'une classe parent a bien une classe enfant avec une méthode de même nom et signature ?

Non pas vraiment puisque l'idée est justement de permettre d'avoir autant de classes enfants que nécessaire et d'en ajouter.
D'autant que la classe enfant peut être définie dans un autre fichier, compilée à un autre moment, etc.