Instanciation d'interface ?

Bonjour à tous,

je viens d'être balancer sur un projet c++, et ce n'est pas trop mon rayon. Je suis dans une grosse phase d’apprentissage.
Le projet est assez gros, avec plein de choses dedans, très intéressantes, mais je me heurte à une première difficulté de compréhension qui doit venir de mon manque de connaissance cpp.

Le main de ce projet est :

Code:

---

1 2 3 4 5 6 7 8 9

// Get application instance IApplication& app = IApplication::getInstance();   // Initialize application if (app.init(argc, argv)) { // Start application ret = app.start();

---

Assez simple, mais pour moi

Code:

---

IApplication& app = IApplication::getInstance();

---

ça c'est assez flou. C'est bien une interface ? (interface étant équivalent à abstrait en c++ ?)
Comment peut on initialiser une interface ?

Surtout qu'après

Code:

---

1 2 3

app.init(argc, argv)   app.start()

---

ces méthodes sont bien lancées, mais je ne comprend pas où le main trouve ces méthodes.

Un concept doit m'échapper....

Plus que le C++, c'est peut-être les Design Pattern qu'il faut un peu réviser. :mouarf:
A ma connaissance, le concept d'interface n'a pas de définition en C++, à part dans la version M$ du C++ (s'il la maintiennent encore et c'est pas dit).

Ce I de "IApplication", c'est bien pour indiquer une "interface" en terme sémantique, il n'y a pas de définition strict de ce qu'est une interface.
Ici "IApplication" est une simple classe (vraisemblablement abstraite via le mot clé "abstract") avec une simple méthode statique getInstance.
Ceci est l'implémentation habituelle de Design Pattern "Singleton" (l'un des plus décrié par un mauvais usage abusif).

Citation:

---

ces méthodes sont bien lancées, mais je ne comprend pas où le main trouve ces méthodes.

---

Dans le Singleton, l'instance (unique par l'utilisation de Design Pattern) de type IApplication (ou d'une classe fille de IApplication).

Ne pas pouvoir instancier une interface n'interdit pas d'en utiliser, sinon elles n'auraient aucun intérêt.
Il suffit qu'une classe en hérite.
Avec un tel code, ma boule de cristal voit que la classe qui l'implémente enregistre son instance afin d'être retrouvée via ce GetInstance. Il s'agit peut-être d'un singleton.
Bien sûr ce ne sont que des théories sans voir le code. Mais la lecture du simple code de getInstance devrait indiquer comment ça marche en 1/2s :calim2:

Merci pour ces précisions. Effectivement le Singleton n'est pas un patern qui m'est familié.

Ce qui me perturbe c'est que juste en appelant le getInstance de la classe abstraite on puisse avoir l'objet en lui même.

Ou alors vu que c'est un Singleton , lors de la compilation le programme sait déjà ou trouver la définitions de la méthode ?

Non tu ne récupères pas l'objet mais une référence, et ça n'a rien à voir.
Lire un bouquin ou des cours sur les bases du langage ne serait pas du luxe.
Et de toutes façons une fonction peut bien retourner ce que bon lui chante alors je vois pas ce qui peut être perturbant ou non :weird:
Et si tu as accès au code, lis-le! Tu verras qu'il n'y a rien de magique derrière ce getInstance.

https://cpp.developpez.com/faq/cpp/?...erence-de-type

Merci de prendre le temps de me répondre.
Manifestement je ne suis pas clair sur ce qui est une difficulté de compréhension pour moi. Je vais tenter de reformuler.

J'ai un main. Dans ce main j'appelle une methode d'une une instance d'une classe abstraite. Cette méthode n'est défini que dans la fille qui hérite de cette classe abstraite.

Je ne comprend donc pas où se fait le lien entre mon instance dans le main, et la définition de la méthode getInstance.


J'ajouterai peut être juste que j'ai commencé par dire que le c++ n'était pas connu pour moi. Si je viens poser une question ici, c'est pour soliciter de l'aide, ainsi qu'une explication pédagogique. Bien entendu Je je vais devoir étudier le sujet, lire le code, et passer du temps pour me mettre a niveau.
Je ne suis pas convaincu de l'utilité de bien insister sur le fait que je ne comprend pas, je suis la pour ça.

Tu lis le code, ou mieux tu demandes à un collègue de t'aiguiller pour le lire avec toi et te l'expliquer.
Les chances que tu sois balancé seul sans aucune équipe autour sur un projet dont tu ne connais même pas le langage utilisé sont assez faibles... ou ton employeur a un gros problème.
Tu prends ton IDE préféré et regardes la magie derrière getInstance, découvres sans trop m'avancer que c'est un simple return xxx;
Tu cherches ce xxx dans le reste du projet où il est assigné. Voilà tu sais d'où sort ce que getInstance retourne. Avec un breakpoint tu peux même savoir quand il est assigné et avoir le chemin d'appel complet.
Avec un autre breakpoint tu peux même step-in dans l'appel et voir l'appel réel.
Redéfinir une fonction virtual dans une classe fille c'est le B.A.BA de l'héritage et du polymorphisme. Encore une fois, si on ne pouvait pas faire ça, une interface et une fonction virtual pure ne serviraient à rien parce qu'on pourrait rien en faire..
Si ces quelques mots ne te disent rien que peut-on faire de plus ? Tu ne comprendras pas plus ce qu'est une vtable, le typage statique et dynamique ou tout autre sujet plus compliqué du langage.
Y'a une fonction virtual, elle existe dans la classe fille uniquement. Et après ? :koi:

Rien qui ne soit accessible dans le menu plus haut.
https://cpp.developpez.com/cours/
https://cpp.developpez.com/faq/cpp/?...-polymorphisme
https://cpp.developpez.com/faq/cpp/?...me-d-inclusion
https://cpp.developpez.com/faq/cpp/?...me-d-inclusion
https://cpp.developpez.com/faq/cpp/?...ot-cle-virtual
https://cpp.developpez.com/faq/cpp/?...-si-importante
https://cpp.developpez.com/faq/cpp/?...t-en-Cplusplus
https://cpp.developpez.com/faq/cpp/?...virtuelle-pure
https://cpp.developpez.com/faq/cpp/?...asse-abstraite

Citation:

---

Envoyé par delta07

J'ai un main. Dans ce main j'appelle une methode d'une une instance d'une classe abstraite. Cette méthode n'est défini que dans la fille qui hérite de cette classe abstraite.

---

Citation:

---

IApplication& app = IApplication::getInstance();

---

Je pense que tu fais fausse route. Tu appelles une méthode statique : il y a :: entre IApplication et getInstance(). Nul besoin d'une instance pour appeler une méthode statique et donc IApplication peut très bien être abstraite.

J'ai déjà vu du code comme ça, tu es peut-être dans un cas similaire :

Code:

---

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 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

#include <iostream> #include <cassert>   class IApplication { public: static IApplication& getInstance();   IApplication() = default; IApplication(const IApplication&) = delete; IApplication& operator=(const IApplication&) = delete;   virtual void run() = 0;   protected: static IApplication* pInstance; };   IApplication& IApplication::getInstance() { assert(pInstance != nullptr); return *pInstance; }   IApplication* IApplication::pInstance = nullptr;   //---------------------------------------   class ConcreteApplication : public IApplication { public: ConcreteApplication() { pInstance = this; }   void run() override { std::cout << "Go go go!" << std::endl; } };   //---------------------------------------   ConcreteApplication application;   int main() { auto& app = IApplication::getInstance(); app.run();   //auto forbidden = IApplication::getInstance(); // error: cannot allocate an object of abstract type 'IApplication' }

---

Salut Bktero, merci de tenter de me faire comprendre.

Effectivement c'est un peu ce qui se passe dans mon code, à ceci prêt que mon getInstance dans mon IApplication est vide.

Code:

---

1 2	/* Get the current application instance */ static IApplication& getInstance();

---

Et dans ma classe fille

Code:

---

1 2 3 4 5 6

/* Get the current application instance */ static MApplication& getInstance() { return m_application; }   /* Singleton = unique global variable in the application to garantee instanciation order */ static MApplication m_application;

---

Ce qui m'échappe c'est le lien entre le main où est appelé la méthode getInstance et l'éxecution de la méthode dans la classe fille.
Du coup ma question est, est ce le compilateur qui fait le lien entre le fait que ce soit un singleton et donc le compilateur SAIT que lorsqu'on doit appeler getInstance de IApplication alors il SAIT que c'est le getInstance de la classe fille ?

Car pour moi, depuis le main ou depuis monIApplication.h il n'y a aucun lien avec la classe fille MApplication.

Encore merci.

Et bien il faut trouve le corps de getInstance()... Dans un IDE, tu fais CRTL+Click, tu cliques-droit et tu fais "open definition", ou un truc comme ça. Sinon il te reste toujours la bonne vieille recherche textuelle.

Il y a une couille dans le potage.
Vous utilisez correctement tout le vocabulaire POO, vos raisonnements semble montré une relative bonne maitrise des concepts POO.
Mais vous semblez bloquer sur l'un des Design Pattern les plus simples, le Singleton.
On doit très vraisemblablement louper un truc dans votre problème.
Tel que vous présentez le code, il ne peut pas compilé.
Je ne dis pas qu'il ne peut pas compiler, mais que s'il est compilable, il y a des trucs que vous ne nous avez pas indiqué.
S'il compile, utilisez le débogueur pour voir comment le compilateur se démerde pour générer un code correct.
S'il ne compile pas, le message d'erreur, SVP.

[TROLL]

C'est limite bon signe de ne pas connaitre Singleton :ptdr:

[/TROLL]

Citation:

---

Envoyé par delta07

Effectivement c'est un peu ce qui se passe dans mon code, à ceci prêt que mon getInstance dans mon IApplication est vide.

Code:

---

1 2	/* Get the current application instance */ static IApplication& getInstance();

---

---

Ceci est un prototype, pas une fonction vide.
Et la fonction est obligatoirement implémentée quelquepart sinon ça linkerait pas vu que c'est utilisé dans le main d'après ce que tu racontes.

Citation:

---

Envoyé par delta07

Ce qui m'échappe c'est le lien entre le main où est appelé la méthode getInstance et l'éxecution de la méthode dans la classe fille.

---

Héritage, relation est un, polymorphisme, typage dynamique.