Klasse, aber nicht die cpp weitergeben?

Unix-Tom

Alle Funktionen die expotieren und MFC beinhalten müssen auch noch

AFX_MANAGE_STATE(AfxGetStaticModuleState());

Haben

CMatt

^^ würde ich dir nicht unbedingt empfehlen.

Soll das ding irgendwann an ein Projekt ran das nicht mit dem VC++ compiliert wird gibts probleme. Definiere in der header besser ein rein virtuelles interface deine klasse und exportiere ne funktion welche dir ne instanz erzeugt. Ist besser als die ganze klasse zu exportieren.

CMatt

btw. mein post bezog sich auf den von Tow-B.de nicht von Unix-Tom (war wohl etwas langsam beim tippen )

Tow-B.de

@Unix-Tom:
AFX_MANAGE_STATE(AfxGetStaticModuleState()); brauchst du definitiv nicht wenn du die ganze Klasse exportierst.

@CMatt:
Genau, das habe ich ja dazu geschrieben. Aber bei uns hier ist es zum Beispiel so das es mit Sicherheit nicht anders kompiliert werden wird. Höchstens mit ner neueren Version des MS-Compilers. Aber ich habe ja extra dazugeschrieben das es nur unter der Bedingung funktioniert. Wenn man sicher ist das es nicht anders benutzt werden wird geht es so einfach erheblich einfacher.

mfg
tobi

mathi

@Tow-B.de: Die Methode funzt erstmal. Danke!

@CMat: wie würde so ein virtuelles Interface und die Instance-Erzeugende Funktion denn aussehen?

@Unix-Tom: Ich verwende MFC-Objecte innerhalb einiger Funktionen meiner Klasse(n). Ich habe aber bei meinen ersten kurzen Test keine Probleme feststellen können. Wie muss ich den Macro denn Awenden? Einfach als erste Anweisung in jede MFC-enthaltenen Funktion?

John Doe

Mach ne COM-DLL draus. Dann brauchst du dir, unter Windows und nur unter Windows, keine Gedanken um die Programmiersprache oder gar den Compiler deines "Anwenders" zu machen.

mfg JJ

CMatt

@CMat: wie würde so ein virtuelles Interface und die Instance-Erzeugende Funktion denn aussehen?

bsp:

// deine header mit dem interface
// Das gibts du dann wieter

class IMyClass // interface zu deiner klasse - rein virtuel
{
public:
   virtual void MyMethod() = 0;
   virtual void Release() = 0;
};

// ne funktion zum erzeugen eines objects die exportiert wird
MY_API void CreateMyClass(IMyClass **pClass);

// deine code in der dll

// implementation deiner klasse - sieht keiner ist in der dll
class CMyClass : public IMyClass
{
public:
void MyMethod1(){
// bla
}
void Release() {
  delete this;
}
};

// deine exportiere funktion
MY_API void CreateMyClass(IMyClass **pClass)
{
  *pClass = new CMyClass();
}

und so verwendet es dann der user:

IMyClass *pMyClass = NULL;
CreateMyClass(&pMyClass); // erzeuge ein object
pMyClass->MyMethod(); // mach was damit
pMyClass->Release(); // lösche es wieder wenn fertig

Unix-Tom

mathi schrieb:

@Unix-Tom: Ich verwende MFC-Objecte innerhalb einiger Funktionen meiner Klasse(n). Ich habe aber bei meinen ersten kurzen Test keine Probleme feststellen können. Wie muss ich den Macro denn Awenden? Einfach als erste Anweisung in jede MFC-enthaltenen Funktion?

In bestimmten Situationen brauchst du das. Einfach als erste Zeile jeder Funktion.

Tow-B.de

@Unix-Tom: Ich verwende MFC-Objecte innerhalb einiger Funktionen meiner Klasse(n). Ich habe aber bei meinen ersten kurzen Test keine Probleme feststellen können. Wie muss ich den Macro denn Awenden? Einfach als erste Anweisung in jede MFC-enthaltenen Funktion?

Du brauchst es vor allem wenn du die vielen verschiedenen anderen Möglichkeiten Dlls und ihre Schnittstellen benutzen willst.

Aber wie man hier ganz klar merkst führen viele Wege nach Rom, die einen sicherer, die anderen schneller und noch wieder andere auf breiteren Wegen, musst natürlich immer selbst entscheiden was für dich am passendsten ist

mathi

Dank euch allen für die ganzen Hinweise und Beispiele,
damit habe ich erstmal einen Guten Startpunkt für das Thema DLL/Lib.

Ganke und Gruss mathi

mathi

Hallo nochmal, da habe ich doch noch eine Frage:

Unterscheiden sich die <Debug>.lib von der <Release>.lib?

Unix-Tom

Ist auch nicht anderes als bei der EXE. Es werden Debuginfos mitkomp.
Für dich solltest du beide erstellen da du ja auch Debuggen willst.

mathi

Die EXE würde ich dann aber eher mit der DLL vergleichen. Allerdings meine ich die lib-Dateien, die sich im Degug- bzw. Release-Verzeichnis befinden.

Die beiden Dateien sind gleich gross. Allerdings scheinen sich die Dateien nur am Anfang in einer Grossen Zahl zu unterscheiden, die sich aber auch mit neu-Compilieren ändert, also wohl nur eine Art Versions-Info

Ich denke mal, es ist egal, welche der lib's ich benutze, jede der lib's sollte sowohl für Debug- als auch Release-Modus funktionieren, oder?

Gruss mathi

Unix-Tom

Ich habe das immer so gemacht. Eine LIB/DLL für Release eine für Debug.
An die Debug hänge ich immer hinten ein "D" an. Wenn man die Debug/LIB einbindet wird auch die DEBUG/DLL geladen.
Vergisst man das man eine DEBUG/DLL vor sich hat und gibt die weiter kann man gleich den Sourcecode weiter geben.