4. externer code - frage

externer code - frage

  • S

    Hallo

    Gibt es eine Möglichkeit, eine exterene dll, lib, active-x control o.ä. zu verwenden OHNE dass sein Header mir bei meinem Projekt bekannt ist? Es wäre nur möglich, dass der externe Programmierer meine Schnittstelle kennt.

    Das wäre also so: Ich würde gerne dem externen Code mit einer definierten Funktion rufen, sagen wir mal
    PExt->Process(BYTE *PData, long len);

    Der externe Code macht was mit dem Buffer und ich verwende ihn modifiziert weiter.

    Weiterhin stelle ich dem externen Projekt eine graphische Ausgabefläche zur Verfügung, wo er seine Datenmanipulation parameterisieren kann ( Slider, Buttons)

    Um unabhängig gegen Erweiterungen zu sein sollte das ganze wie gesagt funktionieren ohne dass ich seine Header einbinden und mein Projekt neukompillieren muss.
    Also z.B. ich kopiere alle externen Projekte als File in Verzeichnis, und was sich darin befindet, das biete ich dem Benutzer als Auswahl an.
    Bei einem Active-X, was wohl durch die Möglichkeit der Darstellung in einem View dem Ganzen am nächsten kommt, muss ich ja leider auch den Header einbinden.

    Ist so etwas möglich, wenn ich z.B. eine Schnittstelle bei mir definiere die der andere verwenden muss?

    Danke & Gruß
    Stefan

    0

  • Ja, das ist möglich, man nennt es auch (dynamisch geladene) "Plugins".
    Was du machst ist (wie du selbst schon angedacht hast), dass du eine Schnittstelle definierst die die "Plugin DLL" zu implementieren hat.
    Das kann z.B. so aussehen dass du vorgibst es muss eine Funktion namens "GetPluginInterface" geben, die einen Zeiger auf eine bestimmte Struktur zurücckgibt. In dieser Struktur können dann z.B. Funktionszeiger drinnen sein, oder was auch immer. Die Struktur gibst du in einem Headerfile vor, welches dann von "Plugin DLLSs" eingebunden werden kann.

    Was du in deinem Interface verwenden kannst hängt davon ab welche Vorgaben du an die Plugin DLLs machen kannst/willst.

    Ich würde hier mal grob 2 Extremfälle unterschieden.

    1. Du gibst den Compiler vor, die STL, die Compiler-Einstellungen, und die zu verwendende Runtime Version (DLL Runtime!). In dem Fall kannst du eine vollständige C++ Schnittstelle machen, also z.B. kann die Struktur auf die dir die Plugin DLL einen Zeiger gibt dann auch virtuelle Funktionen etc. haben.

    2. Du gibst "nichts" vor. In dem Fall musst du mit C kompatiblen Funktionszeigern arbeiten und musst das Interface auf das beschränken was in einer "Win32 DLL" möglich ist, also einfache Strukturen, keine C++ Features etc. Speicher der in der DLL angefordert wird muss auch in der DLL wieder freigegeben werden und so fort.
      Als Beispiel dafür kannst du dir ansehen wie WinAmp das mit DSP Plugins macht.

    Es gibt auch noch mögliche Mittelwege, z.B. wie es das Foobar Projekt macht (oder gemacht hat, hab' da lange nichtmehr reingesehen). Die verwenden MSVC, welche Version ist dabei aber ziemlich egal. Das Interface ist C++, aber eben so "beschränkt" das es möglich wird Code von verschiedenen MSVC Versionen und verschiedenen Runtimes zu mischen ohne dass es zu Problemen kommt. Also z.B. überschreibt jede Klasse operator new und delete, es werden keine STL Klassen verwendet etc. Virtual Calls sind aber OK. Wie es mit virtueller Vererbung und RTTI (dynamic_cast etc.) aussieht weiss ich nicht. So einen "Mittelweg" würde ich dir aber eher nicht empfehlen, da das schon einiges an Wissen über die verwendeten Compiler und mögliche Fallstricke voraussetzt.

    0
  • S

    Hi

    Danke für die Auskunft, hatte leider keine Zeit früher zu antworten.

    Plugin ist wohl das richtige Stichwort, werde mich mal weiter schlaumachen über die Möglichkeiten. Gerade WinAmp ist ein gutes Stichwort, da es auch was mit Sound zu tun hat. Version 2) scheint mir am liebsten, aber wenn das Plugin noch Grafik mitbringen soll wirds wohl schwierig. Das die DLL ihren Speicher selber wieder aufräumt halte ich für selbstverständlich btw 🙂

    Gruß
    Stefan

    0

  • Das die DLL ihren Speicher selber wieder aufräumt halte ich für selbstverständlich btw

    Naja, ich meine solche Sachen:

    // DLL:
std::string Test234()
{
    return "234"; // Speicher wird hier angefordert
}

// Applikation:

void Hmpf()
{
    std::string s = Test234();
} // Speicher wird hier freigegeben

    Anders gesagt: wenn man irgendwelche Instanzen von irgendwas rumreicht kann es leicht passieren dass "Hinter der Bühne" Speicher angefordert/freigegeben wird. Da kann es leicht sein dass Speicher in einer DLL angefordert wird, und in einer anderen (oder der EXE) wieder freigegeben.

    0
Anmelden zum Antworten