Ich hoffe, man versteht mein Anliegen

Grüße
Florian

Zu Funktionspointer in C/C++:
http://www.newty.de/fpt/index.html

Grüssli

Ich will auch nochmal etwas näher in die Details gehen, dass ich noch etwas besser verstanden werde. (ich rede hier mal von dll statt shared library)

Also, ich habe zum einen die Hauptanwendung und die DLL. Die Hauptanwendung hat ein Objekt vom der Klasse Client. Diese Klasse hat verschiedene Methoden und Attribute. Dann wird die DLL vom Hauptprogramm dynamisch zur laufzeit geladen und eine Funktion der DLL aufgerufen. Dieser Funktion wird ein Pointer auf das Client-Objekt übergeben. Die DLL soll jetzt auf die Methoden des Client-Objektes Zugreifen können, OHNE, dass die entsprechenden Methoden beim Kompilieren der DLL mit ringelinkt wurden.
Das würde zum einen die DLL verkleinern, weil die Methoden dann nur einmal vorhanden sind (im Hauptprogramm), statt in beiden Teilen und würde auch die Wartung vereinfachen, weil man die Methode nur noch im Hauptprogramm ändern muss, aber nicht mehr in den DLLs.

Mit Funktionspointern bzw. Funktors hab ich auch schon überlegt, aber das währe ein extremer Aufwand, wenn das Hauptprogramm viele Objekte mit vielen Methoden zur Verfügung stellt, gibt es da auch was komfortableres?

du musst dann in der dll natürlich die header-datei includen.

die implementierung der methoden kann dann aber in dem hauptprogramm liegen.

wenigstens klappt das bei mir so, das geht dann auch zwischen dlls untereinander.

ciao,
jenz

Danke!

Ich wusste bis jetzt durchaus, was virtuelle Methoden sind, aber ich wusste nicht, dass das auch geht ohne den code zu kennen, der später da rein kommt

Ich habe jetzt die Methoden virtuell gemacht und die dll linkt auch, aber sobald ich aus der DLL heraus eine der Methoden aufrufen will stürzt mir das Programm ab

eigentlich müsste das funktionieren.

jenz

Wird vor allem später dann blöde sein, wenn ich DLLs/Plugins von Drittanbietern haben sollte, dann müssen die ja jedes mal neu Kompiliert werden, wenn sich etwas an der API ändert

Ich meinte eher das folgende:
Wenn wir mal von einem Socket-Objekt aus einer Netzwerk-Klasse ausgehen und sagen wir mal, das hat Funktionen zum connecten, senden und empfangen und wird von dem Plugin benutzt.
Jetzt kommen aber noch Funktionen für einen Server, also zum beispiel listen dazu, dann müsste, wenn ich das richtig sehe, bei der vorgehensweise mit den virtuellen methoden, gleich alle plugins, die so einen socket benutzen neu kompiliert werden, auch wenn sie die listen-methode gar nicht verwenden.
Wenn ich zum Beispiel funktionspointer benutzen würde, währe das nicht der fall, aber funktionspointer sind eben um einiges aufwendiger, als virtuelle methoden.

warum nimmst du dann nicht einfach eine weitere "virtuelle plugin klasse" her?

Und dann mit dynamischen Casts herausfinden, um welche Klasse es sich wirklich handelt...

jenz

ableiten wäre wahrscheinlich am sinnvollsten.
Wenn ich das jetzt richtig verstanden habe funzt es ja so, dass eine dll geladen und von ihr ein Objekt an das Hauptprogramm übergeben wird, oder?
Oder funktioniert es andersrum? Egal, jeweils der der das Objekt empfängt muss halt im Rahmen seiner Kenntnis herausfinden, um was für einen Typ es sich handelt.
Du übergibst ja bestimmt nur einen Pointer, oder?

Zeig doch mal ein bisschen Code, wo dein Problem auftreten könnte. Das ist so luftleer einfach unklarer zu erklären...

jenz

Hier die DLL-Files

main.cpp

#include <iostream>

#include <windows.h>
#include "client.h"

using namespace std;

#define _DLL_FUNCTION extern "C" __declspec(dllexport)

_DLL_FUNCTION void myFunc(Client *myclitest);

// a sample exported function
void myFunc(Client *myclitest)
{
    cout << "Calling Client-Function" << endl;
    myclitest->ShowString();
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
            // attach to process
            // return FALSE to fail DLL load
            break;

        case DLL_PROCESS_DETACH:
            // detach from process
            break;

        case DLL_THREAD_ATTACH:
            // attach to thread
            break;

        case DLL_THREAD_DETACH:
            // detach from thread
            break;
    }
    return TRUE; // succesful
}

client.h

#ifndef CLIENT_H
#define CLIENT_H

#include <string>
#include <iostream>

using namespace std;

class Client
{
    public:
        Client(string initStr);
        virtual ~Client();
        virtual void ShowString();
};

#endif // CLIENT_H

Hier das Hauptprogramm

main.cpp

#include <iostream>
#include <windows.h>

#include "client.h"

using namespace std;

typedef void (WINAPI * p_myFunc) (Client *myclitest);

int main()
{
    Client* myCli = new Client("ichbins");
	cout << "Loading DLL" << endl;

    HINSTANCE dllInstance = LoadLibrary("testdll/testdll.dll");

    if (dllInstance == NULL)
    {
        cout << "Can not load!" << endl;
        return 1;
    }

    p_myFunc myFunc = (p_myFunc)GetProcAddress((HMODULE)dllInstance, "myFunc");

    if (myFunc == NULL)
    {
        cout << "Error" << endl;
        return 1;
    }

    cout << "Calling DLL-Function" << endl;
    myFunc(myCli);

	return 0;
}

client.h

#ifndef CLIENT_H
#define CLIENT_H

#include <string>
#include <iostream>

using namespace std;

class Client
{
    public:
        Client(string initStr);
        virtual ~Client();
        virtual void ShowString();
        void check();
    private:
        string myStr;
};

#endif // CLIENT_H

client.cpp

#include "client.h"

Client::Client(string initStr)
{
    myStr = initStr;
}

Client::~Client()
{
}

void Client::ShowString()
{
    cout << myStr << endl;
}

So. Soweit funktioniert das Beispielprogramm auch. Jetzt zu meinem Problem.
Gehen wir mal davon aus, die DLL kommt von einem Drittanbieter und es gibt auch noch eine Reihe Anderer.

Jetzt füge ich eine neue Funktion

virtual void SetString(string newString);

zu der Client-Klasse im Hauptprogramm hinzu, damit die Dlls bei Bedarf noch etwas mehr machen können.
Jetzt muss ich aber alle Dlls neu kompilieren, bzw. kompilieren lassen, da die VMT der Klasse Client in dem Hauptprogramm und in den Dlls nicht mehr übereinstimmt.

ja, stimmt. die könnte sich verändern. wahrscheinlich auch dann, wenn man ableitet.
aber eigentlich sollte die sich nicht mit jeder neuen methode vergrößern, die reservieren meist mehr platz als nötig. aber das ist dann natürlich compilerabhängig. also eher unsicher und damit unbrauchbar.

wie wäre es, wenn du für neue funktionalitäten neue klassen einführst und dazu auch passende myfuncs, dann kannst du daran entscheiden, welche klasse die dll haben will und übergibst eben die entsprechende.
dann ändert sich die gemeinsame header datei nicht mehr..

warum hast du eigentlich zwei client.h dateien gepostet?

ciao,
jenz

class SocketInterfaceVersion1
{
  public:
  //Methoden
};

class SocketInterfaceVersion2 : public SocketInterfaceVersion1
{
  public:
  //Neue Methoden
};

b) Du benutzt die Interfaces nicht mehr direkt sondern über Proxies welche automatisch für jedes Plug-In die passende Version raussuchen.
Einen Artikel dazu gibts hier

Ich hab zwei client.h gepostet, weil die eine die ist, die in der DLL verwendet wird und die andere die, die im Hauptprogramm verwendet wird.

Mit den Proxys, das schau ich mir mal an, das könnte eventuel was sein.

Du exportierst Klassen (auch wenns nur C++ Schnittstellen, also abstrakte klassen sind). d.h. dein Programm und dein Plugin sollten mit dem selben compiler uebersetzt sein, und paar compilerflags muessen auch uebereinstimmen.

Prinzipiell sollten dann auch nur rein abstrakte klassen und Zeiger auf diese klassen sowie POD's teil deiner schnittstelle sein. Insbesondere halb auskompilierte klassen und per tamplate generierte klassen sollten nie teil deiner schnittstelle sein. Wenn da bestimmte compilerflags ned 100% identisch sind kanns schon schiefgehen. Zum beispiel sollten std::string und std:: - container kein Bestandteil deiner schnittstelle sein, das macht die compilereinstellungen gefaehrlich ....

Die Interfaces sollten auch nur in einer ! Headerdatei defininiert werden, welche dann von App und plugin gemeinsam genutzt werden. Sobald dann irgendwie nen unresolved symbol kommt, weil irgendwo ne definition fehlt, dann weisst das an deinen Schnittstellen noch was faul ist ....

willst du wirkliche unabhaengigkeit bei solchen schnittstellen, wirst um plain c nicht drumherumkommen ... da iss dann alles compilerunabhaengig ...

Die Reihenfolge in der VMT ist eigentlich definiert ! Und zwar sobald du immer nur funktionen "hintenanhaengst" wird eine aelter version der klassendefinition mit der neuen vmt noch funktionieren. Nur solltest das mit allen mitteln vermeiden. Ableiten dder schnittstellen um zu erweitern ist besser und sicherer.

Ciao ...

Besser:

Client_if.h

class IClient
{
protected:   // annahme, nur deine Anwendung soll IClients erstellen koennen 
    // leerer CTor und DTor 
    IClient(){}
    virtual ~IClient(){}
public:
    virtual void ShowString() = 0;
};

Das waer deine schnittstelle, ... nun brauchst noch ne Impl dazu
ClientImpl.h

class ClientImpl : public IClient
{
public:
    ClientImpl(std::string strinit);
    virtual ClientImpl();

    // und wir muessen die abstrakte funktion auch definieren .... 
    virtual void ShowString(); // diesmal definiert ! 
};

die CLientImpl.cpp solltest nu selber hinbekommen

deine main funktion !

int main()
{
    // Client* myCli = new Client("ichbins"); // warum dynamisch ? 
    ClientImpl cli("ich bins!");
    cout << "Loading DLL" << endl;

    HINSTANCE dllInstance = LoadLibrary("testdll/testdll.dll");

    if (dllInstance == NULL)
    {
        cout << "Can not load!" << endl;
        return 1;
    }

    p_myFunc myFunc = (p_myFunc)GetProcAddress((HMODULE)dllInstance, "myFunc");

    if (myFunc == NULL)
    {
        cout << "Error" << endl;
        return 1;
    }

    cout << "Calling DLL-Function" << endl;
    myFunc(&cli); // hier nu einfach zeiger auf das statiosche objet uebergeben ...
    // wo war in der alten version  das delete ? 
    return 0;
}

Und in der Dll arbeitest nur noch mit dem Interface !

auszug aaus deiner dll impl

/ a sample exported function
void myFunc(IClient *myclitest)
{
    cout << "Calling Client-Function" << endl;
    myclitest->ShowString();
}

Prinzip verstanden ?

Ciao ...