Container für verschiedene Pointer



  • WeiserCoder schrieb:

    da alle diese pointer verschiedene Typen haben, die erst bei laufzeit bekannt sind,

    😕
    Wie kriegt man das denn in C++ hin? Da kennt man doch den Typ seiner Pointer zu jedem Zeitpunkt genau.



  • leider haben alle klassen KEINE gemeinsame basisklasse....

    also ich versuche das problem noch genauer zu schildern:

    es gibt mehrere DLL dateien in bestimmten verzeichnis (plugins),
    alle die DLL's sollen automatisch dynamisch geladen werden aus bestimmten verzeichnis, und jede von diesen DLL exportiert jeweils eine methode

    "xxx* GetPointer()"
    

    wobei xxx* bei jeder DLL anders ist, z.b. IClassOne*, IAnotherClass* usw... die alle haben keine gemeinsame basisklasse....
    diese zeiger sind alles zeiger auf pure abstract interfaces,

    ich will folgendes realisieren....
    dass bei diesem vorgang alle DLL's automatisch geladen werden und jeweils diese eine methode soll aufgerufen werden, und der zurückgelieferter zeiger soll gespeichert werden, in der art wie

    Pseudocode:
    
    container  c;
    while(lade dlls)
    {
        c.push_back(verschidene zeiger, name der dll);
    }
    

    wobei das problem ist, dass zeiger verschiden sind und keine gemeinsame klasse haben, deswegen kenne ich keinen passenden container dafür

    im code würde ich gerne dann so zugreifen auf diesen container...

    Pseudocode:
    
    IClassOne* p = c["einplugin.dll"];
    p->tu irgendwas;
    

    wobei das ohne cast geschehen soll, das ist das problem, also es müssen alle zeiger schon gecastet im container drin stehen,

    PS: oder gibts da eine art design pattern für das ganze ? bzw kennt jemand eine bessere methode so was zu realisieren ? zwecks: pluginmanager
    gruss



  • Ja da gibts nen Trick: man schafft nen einheitliches Interface für das Pluginsystem



  • @WeiserCoder
    Ein Plugin System funktioniert aber anders. Wenn du Plugins hast, die Instanzen verschiedener Klassen zurückgeben, dann hast du auch verschiedene Plugins. Was ja durchaus möglich ist. Ich benutze zB den Total Commander und da gibt es Lister-, Packer- und Filesystem- Pluigns. Du musst dann aber jeden Typ von Plugin auch separat behandeln. Du nimmst dann einfach einen Container der alle IClassOne* aufnimmt, einen der alle IAnotherClass* aufnimmt usw. Und diese behandelst du dann auch separat.
    Wenn es allerdings Plugins des selben Typs sind, dann musst du es wie SirLant sagte machen. Dh GetPointer() liefert immer zB IClass* zurück.



  • leider kann ich das nicht machen....

    grund:

    es gibt einen PluginManager, der ist schon fest integriert im code und vorkompiliert(dll), also kommt es schlecht in frage, dass es ein neues plugin entwickelt wird mit einem neuen interface, dass ich dann PluginManager erweitern soll, z.b. neue methode rein INeuerPlugin* GetNeuerPlugin();
    das kann ich aber nicht machen, wie gesagt, pluginmanager ist schon vorkompiliert,

    gibts noch evtl andere idee oder möglichkeit das ganze zu lösen ?



  • Damit erweist sich dieser Plugin-Manager aber definitiv als Fehlkonstruktion.

    mfg JJ



  • Sorry WeiserCoder sowas kann nicht funktionieren.



  • Nen Pluginmanager der mit solchen Plugins arbeitet muss aber alle Plugins im voraus kennen, daher kannst du dann ja auch einfach alles hart kodieren.



  • wie würdet ihr denn euren Pluginmanager aufbauen ?

    zweck:
    eine grafikengine, wobei hauptkern als dll da ist, und wenn was neues dazu kommt (plugins) auch als dll geladen werden kann, damit man das auch nutzen kann...

    problem:
    die plugins, die bei entwicklung der engine fertiggestellt werden, kann man problemlos dann bei dem pluginmanager aufrufen mit IVorhanderInterface GetDiesenInterface()...
    bei plugins, die später dazu kommen (wenn engine zum download bereit steht), kann man das nicht machen, da neue Interfacetypen dazu kommen, da pluginmanager schon in einer dll drin ist, kann man solche methoden nicht mehr dazu einfügen wie INeuerInterface
    GetNeuerInterface();...

    gibts da eine andere lösung pluginsystem zu realsieren ? oder lösung für dieses problem ?



  • mach es anders;
    anstatt direkt den pointer zu speichern, kannst du den pointer doch selber wrappen

    struct PointerInfo
    {
       enum PointerType { PT_IBASE, PT_ICLASS, PT_IANOTHER };
       PointerType pointer_type;
       void *pointer;
    };
    

    dann hast du alles was du brauchst und kannst deine pointer einfach verwalten



  • Wie willst du denn ein Plugin benutzen wenn du nicht sein Interface kennst? Dann kannst du doch gar keine Funktionen davon aufrufen. Ich raff das nicht.



  • esskar schrieb:

    mach es anders;
    anstatt direkt den pointer zu speichern, kannst du den pointer doch selber wrappen

    struct PointerInfo
    {
       enum PointerType { PT_IBASE, PT_ICLASS, PT_IANOTHER };
       PointerType pointer_type;
       void *pointer;
    };
    

    dann hast du alles was du brauchst und kannst deine pointer einfach verwalten

    ich verstehe nicht ganz, wie du dann den void pointer casten willst....
    in enum speicherst du ja dann nur die ID's keine pointertypen,
    und zweitens, wie soll dann so in pseudocode so ein pluginmanager aussehen ?
    danke schon mal im vorraus



  • nixraff schrieb:

    Wie willst du denn ein Plugin benutzen wenn du nicht sein Interface kennst? Dann kannst du doch gar keine Funktionen davon aufrufen. Ich raff das nicht.

    doch, interface kenne ich ja dann schon, weil es includet wird, nur das problem ist dabei, pluginmanager hat keine funktion vorraus deklariert genau auf diesen pointertyp zuzugreifen, falls es ein neuer plugin ist, mit neuem interface, da der pluginmanager in einer dll liegt und nicht mehr zu ändern wäre



  • keine Vorstellungskraft? 🙂

    typedef std::map< PointerInfo, std::string > PluginContainer;
    PluginContainer m_container; 
    
    void AddPluginPointer(PointerInfo & pi, const std::string & name)
    {
       m_container.insert(PluginContainer::value_type(pi, name));
    }
    
    void AddPluginIBase(IBase *ptr, const std::string & name)
    {
       PointerInfo pi;
       pi.pointer = (void *)ptr;
       pi.pointer_type = PointerInfo::PointerType::PT_IBASE;
    
       AddPluginPointer(pi, name);
    }
    
    void AddPluginIClass(IClass *ptr, const std::string & name)
    {
       PointerInfo pi;
       pi.pointer = (void *)ptr;
       pi.pointer_type = PointerInfo::PointerType::PT_ICLASS;
    
       AddPluginPointer(pi, name);
    }
    
    void PluginAction()
    {
       PluginContainer::const_iterato iter;
    
       iter = m_container.begin();
       while(iter != m_container.end())
       {
          switch(iter->first.pointer_type)
          {
             case PointerInfo::PointerType::PT_IBASE:
                {
                   IBase *ibase = (IBase *)iter->first.pointer;
                   // mach was mit ibase
                }
                break;
    
             case PointerInfo::PointerType::PT_ICLASS:
                {
                   IClass *iclass = (IClass *)iter->first.pointer;
                   // mach was mit iclass
                }
                break;
          }
          ++iter;
       }
    }
    


  • WeiserCoder schrieb:

    nixraff schrieb:

    Wie willst du denn ein Plugin benutzen wenn du nicht sein Interface kennst? Dann kannst du doch gar keine Funktionen davon aufrufen. Ich raff das nicht.

    doch, interface kenne ich ja dann schon, weil es includet wird, nur das problem ist dabei, pluginmanager hat keine funktion v****** deklariert genau auf diesen pointertyp zuzugreifen, falls es ein neuer plugin ist, mit neuem interface, da der pluginmanager in einer dll liegt und nicht mehr zu ändern wäre

    Genau das versteht ja nixraff nicht, und ich übrigens auch nicht.
    Darf man mal fragen, was der Plugin-Manager macht? Und speziell was du dir vorstellst was der Plugin-Manager mit unbekannten Plugins machen soll?



  • Wenn du nicht nen einheitliches Interface schaffst, dann bleibt dir nur Esskar's Vorschlag übrig und ich finde den für nen Plug-In System mehr schlecht als recht.

    btw. hi esskar 🙂



  • SirLant schrieb:

    btw. hi esskar 🙂

    OT:
    hi. so sieht man sich wieder.
    da es auf perl-community ja zum ausfall kam, musste ich nun wieder hier meinen alten account ausgraben um mein Bedürfnis Hilfe zu geben, befriedigen zu können. 😉



  • oki jungs, danke schön,

    habe jetzt alle plugins von einer leeren abstrakten klasse IPlugin abgeleitet, jetzt gehts, so habe ich eine einheitliche interface für alle

    😉



  • WeiserCoder schrieb:

    oki jungs, danke schön,

    habe jetzt alle plugins von einer leeren abstrakten klasse IPlugin abgeleitet, jetzt gehts, so habe ich eine einheitliche interface für alle

    😉

    und genau so soll es sein


Anmelden zum Antworten