2009-03-07 5 views
0

Es gibt eine Klasse, die in eine DLL kompiliert wirdWie neues Schlüsselwort arbeitet in C#

//HeaderFile.h 
//version 1.0 
class __declspec(dllexport) A { 
    int variable; 
//member functions omitted for clarity 
}; 

//implementation file omitted for clarity 

Sie eine exe bauen, die aus der DLL oben Klasse verwendet es in

#include "HeaderFile.h" 
int main() { 
    A *obj = new A(); 
    obj->CallSomeFuncOnObj(); 

    // 
    //whatever 
    // 
} 

bis bis jetzt kompiliert wurde Ihr Programm funktioniert gut. Aber jetzt Sie Ihre DLL neu kompilieren mit dem folgenden Code

//HeaderFile.h 
//version 2.0 
class __declspec(dllexport) A { 
    int variable; 
    int anotherVariable; 
//member functions omitted for clarity 
}; 

//implementation file omitted for clarity 

und Sie neu kompilieren nicht Ihre exe aber beginnen die neu kompiliert DLL aus dem alten exe verwenden. Was jetzt passieren wird, ist, dass Ihre EXE den Code hat, der memory = sizeof (Klasse A Version 1.0) zuweist, aber der Konstruktor in Ihrer neuen DLL hat Code, der annimmt, dass ihm ein Speicherblock = sizeof (Klasse A Version 2.0) übergeben wird. Es gibt einen Größenunterschied zwischen den beiden - ein Rezept für Unvorhersehbarkeit.

Ein ähnliches Beispiel wird im ersten Kapitel eines ausgezeichneten Buches - Essential COM von Don Box gezeigt. Jetzt zur Frage. In einer ähnlichen Situation in C# (oder einer anderen .Net-Sprache), was würde passieren?

Antwort

2

In COM implementiert Ihre DLL eine Objektfactory: Die DLL erstellt das Objekt selbst, um solche "Synchro" -Probleme zu vermeiden. In .NET instanziiert die CLR das Objekt basierend auf Typwissen aus der DLL, in der der Typ implementiert ist. In beiden Fällen wird das von Ihnen erwähnte Problem vermieden.

Verwandte Themen