Bonjour,

Ma question est quelque peu théorique car j'ai une solution mais qui ne me semble pas "pure".
Ce que j'appelle une interface est une spécification sans code associé (virtuelle pure) par exemple
class Interface
{
    virtual int Run (void) = 0;
    virtual ~Interface ()  = 0;
};


Malheureusement une classe comme celle-ci ne se linke pas dans mon environnement gcc sous MinGW (mais je suppose que c'est vrai avec d'autres compilateurs).

En effet si je déclare:
class Implementation : public Interface
{
    Implementation();
    virtual int Run (void);
    virtual ~Implementation ();
};
int main()
{
    Implementation Programme;
    return Programme.Run();
}


Toute utilisation de Implementation va générer une référence à la fonction Interface::~Interface qui n'existe pas.
Y a-t-il une solution à ce problème sans définir le destructeur (virtual ~Interface (){}) qui mettrait du code dans l'interface - certe pas beaucoup - qui perdrait ainsi son status d'interface pure ?
Je sais je suis un peu tatillon, mais une interface c'est juste une interface

Je n'ai jamais eu de problème avec le destructeur virtuel pure. Mais dans ton cas, ne pas déclarer le destructeur te poserait un problème ?

class Interface
{
    virtual int Run (void) = 0;
};

Mais pour revenir a ton problème, moi j'en vois un autre:
-> ton constructeur n'est pas accessible car déclaré "private".

Effectivement il manque les public:
Il faut considérer que toutes les déclarations de l'interface et de l'implementation le sont. Là n'est pas le problème.

Par contre il me faut effectivement obligatoirement un destructeur virtuel. Sinon si j'utilise mon implémentation comme décrit ci-dessous le destructeur de l'implémentation ne sera pas appelé. Il ne faut jamais interdire lors de la définition d'une interface que l'implémentation ait des destructeurs virtuels sinon on restreint considérablement soit les implémentations (pas de destructeur) soit les utilisations (pas d'utilisation polymorphique ce qui réduit considérablement l'intéret d'une interface!).

int main()
{
    Implementation *Programme = new Programme;
    int Result = Programme.Run();
    delete Programme;
    return Result;
}

Ouuups il fallais évidement lire ceci:

int main()
{
    Interface *Programme = new Implementation;
    int Result = Programme.Run();
    delete Programme;
    return Result;
}

Bon...mais pourquoi ne veux-tu pas implémenter le destructeur de Interface? Tu peux le mettre en inline avec rien dedans par exemple :
class Interface
{
    virtual int Run (void) = 0;
    virtual ~Interface ()  = 0 {return;};
};

de cette manière tu gardes le destructeur comme fonction virtuelle pure, mais il est tout de même implémenté pour l'interface; de toutes façons le compilateur virera l'appel puisqu'il ne fait rien.

Oui en effet, au temps pour moi, pour le coup du destructeur. J'essai de voir, car je suis intrigué par ce problème. J'ai essayé sous devcpp, j'ai le meme soucis.

Bon, mais j'ai cherché autour de moi, la réponse, c'est qu'apparemment, on ne peut pas faire ce que tu souhaites avec le C++.
Donc le problème vient de ta conception. Tu ne peux pas gérer une interface comme un objet et donc on ne peut pas détruire une interface.
Donc l'objet Implementation doit être détruit par celui qui a créé ton objet.

Non Juju12, car dans ton cas, la classe Interface n'est plus une interface et chaque objet de type Interface* possède une vtable, et donc Giles314 aura de gros ennui plus tard s'il commence a faire de l'héritage multiple à cause de l'héritage multiple. Sauf si dans la structure du programme de Giles314, l'héritage multiple ne présente pas de pb.

Salut,

Pour l'héritage multiple il faut déclarer la dérivation viruelle :

class Implementation : virtual public Interface
{
};

Je ne vois pas bien à quoi l'héritage multiple pourrait être une solution au problème.
J'ai un peu peur que Luthor ait raison et qu'on ne puisse par faire une interface pure en C++. C'est aussi vers cette conclusion que mes essais m'avaient conduit. Mais j'ai du mal à m'y résoudre car le concept d'interface est quand même un pilier de la conception objet et je n'imagine pas que les travaux de normalisation du C++ n'ait pas ouvert la possibilité de créer une interface pure. Mais il est vrai qu'en autorisant l'implémentation d'une méthode virtuelle pure le C++ permet une ineptie totalement inutile mais qui semble interdire d'implémenter proprement un concept de base.

Sinon la proposition de Juju12 est correcte et correspond à la façon dont j'approche aujourd'hui au plus près le concept d'interface (sauf que perso je ne mets même pas le return dans le destructeur car les accolades suffisent). Si bien qu'on obtient ce que Luthor dit ne pas être possible (et effectivement j'aimerai ne pas le faire) c'est à dire "gérer une interface comme un objet" et fournir une méthode pour "détruire une interface."

"C++ permet une ineptie totalement inutile mais qui semble interdire d'implémenter proprement un concept de base."
=> Il ne l'interdit pas. Mais une interface n'est pas faite pour etre détruite. Elle ne décrit qu'un aspect fonctionnel de l'objet et elle ne peut être considérée comme l'objet lui meme. Donc ce n'est pas le C++ qui interdit de le faire, mais la théorie qui dirait que : détruire une interface n'a pas de sens et ne résulte que d'une mauvaise conception.