In einem DLL-Projekt wird eine Klasse definiert, welche von mehreren Basisklassen erbt. Sowohl in den Basisklassen als auch in der Klasse selbst sind alle Methoden virtuell.

Zusätzlich enthält die DLL eine C-Funktion, welche eine Instanz der Klasse erzeugt und (gecastet als eine der Basisklassen zurückgibt).

Die DLL wird dynamisch geladen, die Funktion gesucht und verwendet, um eine Instanz der Klasse zu erstellen. Die Applikation, die das tut, nutzt die Header, sodass die Klassendefinition bekannt ist. Die Instanz wird damit zu einer Instanz der eigentlichen Klassen gecastet.

Nun das eigentliche Problem: Unter Visual Studio 2008 hat alles funktioniert. Nachdem die Applikation auf 2010 migriert ist, tritt folgender Fehler auf:

Beim Zugriff auf die virtuellen Memberfunktionen tritt eine Access-Violation auf, welche sich darauf zurückführen lässt, dass die VirtualFunctionTable einer der Basisklassen offensichtlich falsche Werte enthält.

Das kuriose daran ist, dass der Fehler nur in der Releaseversion der DLL auftritt. Außerdem ist er scheinbar Interpretationsabhängig (Wenn ich an der Stelle das Programm unterbreche und die Basisklasseninstanz mit der Schnellüberwachung betrachte, so sehe ich, dass so interpretiert, die richtigen Werte in der entsprechenden VFT stehen. Betrachte ich eine fertig gecastete Version der Instanz, so sind die Werte der Tabelle falsch).

In der Hoffnung, dass das jemand nachvollziehen kann, und vielleicht einen Hinweis hat noch ein Bisschen stellvertretender Quellcode.

DLL:

class __declspec(dllexport) Klasse1
{
public:
virtual bool Initialize();
}

class __declspec(dllexport) Klasse2: public Klasse1
{
public:
virtual bool Initialize();
virtual void Methode1();
...
}

class __declspec(dllexport) Klasse3
{
...
}

class __declspec(dllexport) Klasse4: public Klasse2, public Klasse3
{
public:
...
virtual bool Initialize();
virtual void Methode1();
...
}

Klasse1* CreateObject()
{
  return (Klasse1*)new Klasse4();
}

Applikation:

m_hDLL = ::LoadLibrary(filename);//DLL dynamisch laden
Create=(Klasse1*())::GetProcAddress(m_hDLL, "CreateObject");//Funktion suchen
Klasse1* obj=Create();//und aufrufen, um Instanz zu erzeugen

obj->Initialize();//wird korrekt aufgelöst (da der Eintrag in der VFT von Klasse1 steht

((Klasse4)obj)->Methode1();//wird nicht korrekt aufgelöst (VFT für die Methoden der Basisklasse Klasse2 enthält ausschließlich falsche Einträge bzw. der Pointer auf die VFT selbst ist 0x00000000, also ungültig)

Hat vielleicht irgend jemand ähnliche Probleme bei der Migration, oder kommt jemandem so ein Verhalten anderweitig bekannt vor?

In einem DLL-Projekt wird eine Klasse definiert, ...
Zusätzlich enthält die DLL eine C-Funktion, welche eine Instanz der Klasse erzeugt...

1. DLLs gehören nicht zum C++ Standard (und sind Systemabhängig), daher ist dies hier eigentlich das falsche Forum.
2. Da C++ keine Binärkompatibilität garantiert, müssen alle Projekte unter dem gleichen Compiler (inkl. Compilerversion) erstellt werden - sofern eine Klassenübergabe überhaupt möglich ist.

1. Dass das hier evtl. nicht das richtige Forum ist, hatte ich mir schon gedacht. Ein Hinweis auf eine bessere Wahl wäre allerdings nicht schlecht gewesen.

2. Ein Problem, welches sich direkt aus der Compilerwahl ergibt, kann es eigentlich nicht sein, da Release- und Debug-Versionen aus Sicht des Compilers ja eigentlich das selbe sind (abgesehen von einigen Flags, welche aber konfigurierbar sind) und wie bereits geschrieben funktioniert es ja mit Debugversion der DLL. Da ich den Compiler beider Projekte nicht verändern kann (Rahmenbedingungen) ist die einfachste Lösung also nicht praktikabel. Interessanter wäre, ob es Compilerschalter (typische Einstellungen eines Compilers unabhängig, ob es diese Option bei Microsoft gibt oder ob sie evtl. anders heißt) gibt, die derartiges Verhalten auslösen könnten.

Falls dazu jemandem noch etwas einfallen würde, wäre ich über weiterführende Hilfe dankbar

iÜ: Falls dies jemand liest, der dazu berechtigt ist, das Thema an passendere Stelle zu verschieben, so kann derjenige das gerne tun.

((Klasse4)obj)->Methode1();

sollte eher

((Klasse4*)obj)->Methode1();

sein. Das obige sollte sich aber auch nicht kompilieren lassen. Außerdem wäre nen dynamic-cast noch schön, da kannste auch prüfen, ob sich obj wirklich in Klasse4 überführen lässt (wirft bad_cast, wenn es sich nich umwandeln lässt)

Wenn es sich bei deinem Problem um nen Linker-Error handelt, hast du vermutlich die LIB-Datei der DLL nicht eingebunden?

SALOMON

Außerdem wäre nen dynamic-cast noch schön, da kannste auch prüfen, ob sich obj wirklich in Klasse4 überführen lässt (wirft bad_cast, wenn es sich nich umwandeln lässt).

Mein dynamic_cast gibt in dem Fall NULL zurück.

EDIT: Hab gerade nomma nachgeschaut... bei Referenzen gibts nen bad_cast (weil auch logischerweise kein 0 zurückgegeben werden kann) und bei Zeigern ist es die 0.

Grundsätzlich sollten in einem C++ Programm keine C-Style Casts verwendet werden.

Lars

Der vergessene Pointer-Stern war natürlich ein Tippfehler im Posting.

Was das dynamische casting angeht, so verwende ich jetzt eine Mischung aus C-casts und dynamic_cast-Anweisungen. (Ist notwendig, da andernfalls zwar mein Zugriff auf die Basisklasse funktioniert, welche bisher versagt hat, dafür klappts bei reinem dynamic_cast bei den anderen nicht mehr)

Ist zwar keine schöne Lösung, aber so gehts wenigstens. In Zukunft werde ich dann darauf achten, mich soweit möglich an den dynamic_cast zu halten.

Also nochmals Danke.

Was das dynamische casting angeht, so verwende ich jetzt eine Mischung aus C-casts und dynamic_cast-Anweisungen. (Ist notwendig, da andernfalls zwar mein Zugriff auf die Basisklasse funktioniert, welche bisher versagt hat, dafür klappts bei reinem dynamic_cast bei den anderen nicht mehr)

Dann machst du etwas falsch. C-Style Casts sind nicht notwendig, es geht immer mit den C++ Casts.

Lars

Klasse1* pClass1=CreateObject();//die zurückgegebene Instanz hat eigentlich den Typ Klasse4*

Klasse4* pClass4_C=(Klasse4*)pClass1;//C-Style cast zu Klasse4

pClass4_C->Initialize();//funktioniert
pClass4_C->Methode1();//funktioniert nicht

Klasse4* pClass4_Dyn=dynamic_cast<Klasse4*>(pClass1);//dynamisch gecastet

pClass4_Dyn->Initialize();//funktioniert nicht (die entsprechende vftable wird an der falschen Stelle gesucht)
dynamic_cast<Klasse2*>(pClass4_Dyn)->Methode1();//funktioniert auch nicht
pClass4_Dyn->Methode1();//funktioniert

ich vermute es liegt am internen Verhalten der DLL, was ich aber nicht wesentlich verändern kann. Ich halte mir deshalb beide Versionen des gecasteten Pointers und nutze jeweils diejenige, die funktioniert.

solltest du zufällig eine Idee haben, warum das einmal geht und das andere mal nicht, würde ich mich dennoch über einen Hinweis freuen

Klasse1* CreateObject()
{
  return (Klasse1*)new Klasse4();
}

Mach das mal so:

Klasse1* CreateObject()
{
  return new Klasse4;
}

ich vermute es liegt am internen Verhalten der DLL, was ich aber nicht wesentlich verändern kann.

Was mir noch immer nicht klar ist: Wurde die DLL mit der gleichen Compilerversion erzeugt?

Was den scheinbar überflüssigen Cast angeht, so kann ich nicht beantworten, warum er verwendet wird. Ich kann lediglich bestätigen, dass er wirklich so im Quelltext steht.

Also sind DLL und Applikation nicht mit der selben Compilerversion erstellt...

Okay, dann erübrigt sich auch jeder Versuch einer Hilfe, da die Compilerversionen vermutlich eine inkompatible binäre Darstellung haben (Ein riesiges Manko von C++ ist die fehlende Binärkompatibilität).

Einzige Lösung die mir einfällt:
Wrapper-DLL unter VS2008 schreiben, die alle Aufrufe in eine C-Schnittstelle umwandelt, den C-Schnittstellen sind im Gegensatz zu C++ Schnittstellen unproblematisch. Oder einen COM-Wrapper...

Wie ich bereits am Anfang beschrieben habe, kann das eigentlich nicht das Problem sein, da alles problemlos funktioniert, wenn ich die Debugversion der DLL verwende. Nur eine in der Releaseversion kompilierte DLL verursacht den Fehler, was mich zum Schluss kommen lässt, dass es ein Konfigurationsproblem bzw. ein Compilerschalter sein müsste.

Debug und Release Dateien sind oftmals unterschiedlich.
Von daher kann es sein, dass du eine gesonderte DLL für den Releasebuild benötigst.

Galatea schrieb:

Also sind DLL und Applikation nicht mit der selben Compilerversion erstellt...

Okay, dann erübrigt sich auch jeder Versuch einer Hilfe, da die Compilerversionen vermutlich eine inkompatible binäre Darstellung haben (Ein riesiges Manko von C++ ist die fehlende Binärkompatibilität).

Einzige Lösung die mir einfällt:
Wrapper-DLL unter VS2008 schreiben, die alle Aufrufe in eine C-Schnittstelle umwandelt, den C-Schnittstellen sind im Gegensatz zu C++ Schnittstellen unproblematisch. Oder einen COM-Wrapper...

Mit Interfaces (Klasse mit nur rein virtuellen Methoden) ist die Interoperabilität auch zwischen verschiedenen Versionen eines Kompiler gegeben.
(Siehe "Imperfect C++" von Matthew Willson).

Simon

Irre ich mich darin denn grundlegend?