Frage zum Aufbau eines DLL-Projektes



  • Hallo,

    ich habe eine Frage zu meinem DLL-Projekt. Diese DLL soll eine externe LIB und DLL einbinden, was für mich auch kein Problem darstellt. Nun möchte ich aber, dass ein weiteres Projekt, also meine Anwendung, die meine DLL nutzt, nichts mehr von der externen LIB bzw. DLL weiss, so dass ich sie in dieser Anwendung nicht extra einfügen muss.
    Wie würde man sowas am geschicktesten lösen?
    Vielen Dank für Tipps!
    V.K.



  • VerbalKint schrieb:

    ich habe eine Frage zu meinem DLL-Projekt.

    Welcher Compiler etc.? DLLs gehören nicht zum C++ Sprachstandard.

    VerbalKint schrieb:

    Nun möchte ich aber, dass ein weiteres Projekt, also meine Anwendung, die meine DLL nutzt, nichts mehr von der externen LIB bzw. DLL weiss, so dass ich sie in dieser Anwendung nicht extra einfügen muss.

    Hört sich nach einem Plugin-System an. Dazu müsstest du für die als Plugin verwendeten DLLs (mit einer statischen Lib geht dies nicht) eine feste Schnittstelle definieren. Und dann die DLLs eines Ordners auf diese Schnittstelle hin prüfen (dynamische/späte Bindung z.B. über die Win32 API: LoadLibrary, GetProcAddress, FreeLibrary).



  • Hi,

    danke für die Antwort. Ich benutze Visual Studio 2005. Ich hatte mir das ganze wie folgt vorgestellt. In einer

    #ifndef MEINE_DLL_H
    #define MEINE_DLL_H
    
    #ifdef  MEINE_DLL
    #define MEINE_DLL_DLL  __declspec(dllexport)
    #else
    #define MEINE_DLL_DLL  __declspec(dllimport)
    #endif
    
    class cMeineDllIntern;
    
    class MEINE_DLL_DLL cTestDll
    {
    public:
      cTestDll ()
      {}
      ~cTestDll(){}
      bool Funktion1();
      bool Funktion2();
    
    private:
      cMeineDllIntern *pMeineDllIntern();
    };
    #endif // MEINE_DLL_H
    

    Das wäre in einer Header wie z.B. MeineDll.h Die dazugehörige MeineDll.cpp würde dann so aussehen:

    bool cTestDll::Funktion1 ()
    {
      return pImgAcquiIntern->Funktion1();
    }
    bool cTestDll::Funktion2 ()
    {
      return pImgAcquiIntern->Funktion2();
    }
    

    Und in einer anderen Header bzw. Cpp wäre dann die Klasse cMeineDllIntern definiert, die alle Daten aus der externen Dll benutzt.
    Kann man das so machen?
    Viele Grüße,
    V.K.



  • Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ in das Forum MFC (Visual C++) verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • asc schrieb:

    DLLs gehören nicht zum C++ Sprachstandard.

    Klar, DLLs sind eigenständige Aufgaben sowohl für den Copiler als auch für den Linker. Antwort: DLL bilden und diese dann von einer Anwendung benutzen. Das wiederum ist seit den Anfängen der Programmierung Standard! Es gibt nur ein paar Unterschiede, ob Konsol-Anwendung oder Windows-Anwendung.



  • berniebutt schrieb:

    Das wiederum ist seit den Anfängen der Programmierung Standard! Es gibt nur ein paar Unterschiede, ob Konsol-Anwendung oder Windows-Anwendung.

    Es gibt Systeme jenseits der MS-Plattform, von den unterschiedlichen Notationen die mir gerade bei etwas älteren Compilern unter Windows begegnet ist, wollen wir hier auch nicht reden. Gepostet wurde ursprünglich im ANSI C++ Forum, und da gehört das Thema DLL - da Systemabhängig - mit Sicherheit nicht hin.



  • asc schrieb:

    Es gibt Systeme jenseits der MS-Plattform ...

    Auch klar! Man konnte DLLs schon einsetzen bevor es MS gab. War allgemeiner Standard auf jedem ordentlichen System vor 30 Jahren und jeder Programmierer konnte damit umgehen.



  • berniebutt schrieb:

    Auch klar! Man konnte DLLs schon einsetzen bevor es MS gab. War allgemeiner Standard auf jedem ordentlichen System vor 30 Jahren und jeder Programmierer konnte damit umgehen.

    Aber sicher, ganz davon abgesehen das sein Beispiel ein Klassenexport/-import ist, und das dies in C++ noch nie normiert war (Geschweige den das dies auch zwischen Unterschiedlichen Compiler oder gar Compilerversionen bereits auf einen System nicht kompatibel sein muss).

    Und auch die Unterschiede so/dll... und wie sie alle heißen deuten schon auf deinen "Standard" hin. Und davon abgesehen bleibt das Rad nicht stehen und dynamsiche Bibliotheken sind auch von der verwendeten Sprache abhängig - sie können gewisse Kompatibilitäten haben - müssen es aber nicht (Selbst unter Windows ist eine dll in ihren Aufbau nicht normiert).

    cu André



  • Da stellt sich dann die Frage: "Wie schreibe ich portable Programmes" Es war und ist immer der kleinste gemeinsame Nenner, damit man mit einer notwendigen Anpassung so wenig wie mögliche Probleme bekommt. War mal lebenswichtigt bei einer Entwicklung auf der Maschine A, die auf der Maschine B laufen sollte. Sollte heute auch noch gelten? DLLs sind Funktionsbibliotheken. Klassen sind sowohl Funktionen wie auch Daten. Ich erwarte da keine Normierung.


Anmelden zum Antworten