Hallo,
ich bin ein absoluter Neuling auf dem Feld von Qt als auch beim Einbinden und Nutzen von Bibliotheken.
Meine Situation ist folgende: Ich habe eine Bibliothek in dll-Form (auch in lib-Form), welche Klassen für die Realisierung einer Client-/Server-Architektur enthält. Weiterhin gibt es ein schon fertiges (MFC-)Programm, welches diese Architektur nutzt. Mein Ziel ist es, diese mit einer QT-basierten GUI zu nutzen.
Ich gehe in kleinen Schritten voran. Mein Ziel ist es erstmal, die dll einzubinden und dann eine Instanz einer darin enthaltenen Klasse zu erstellen.
Ich weiß, daß man die dll statisch bzw. dynamisch einbinden kann. Ich habe beides probiert. Ersteres durch das Setzen des LIB-Pfades in der pro-Datei. Letzteres durch QLibrary-Aufruf. Zumindest das hat funktioniert.
Meine Fragen:
1. Wie kann ich rausfinden, ob ich den LIB-Pfad richtig gesetzt hab und die dll eingebunden ist? Bzw. ist z.B. LIBS += "C:\Users\Megadime\Documents\QT\RTC3D_Test\rtC3Dclient.lib" richtig und ausreichend?
2. Wie kann ich eine Klasse aus der dll instanziieren? Ich habe rumgelesen und viel von dllimport, dllexport usw. sowie Unterschiede zwischen C- bzw. C++-basierten dlls (ich weiß nicht, ob dies der richtige Ausdruck dafür ist) gelesen. Mittlerweile weiß ich eigentlich nicht mehr so richtig, was ich glauben soll bzw. machen soll.
Fragen zum Dll-Import bzw. Klasseninstanziierung
QLibrary ist der falsche Weg. Deine Bibliothek bringt recht wahrscheinlich einen (oder mehrere) Header-Dateien mit. Diese musst du per #include einbinden (wie du das ja schon vom C++-Programmieren kennst). Dann musst du noch dafür sorgen, dass der linker die .dll findet und sie auch zu deinem Programm dazulinkt. (qmake "LIBS"-Variable -> Qt-Doku)
zu 1.
Wenn Lib(statsche bibs) pfade nicht richtig gesetzt sind, und du linkst trotzdem gegen die lib, die er dann natuerlich nicht findet, hagelt es linker-Fehler. Beim VS compiler ziemlich genaue sogar, ala "konnte Link-Target nicht finden ... "
zu 2.
gibt halt mehrere Wege.
der M$ quasi statische Weg, dlls zu nutzen (meist als MFC Erweiterungs-dlls angepriesen):
du linkst eine statische lib, die laed die dll auch im pre-main code. d.h. zur laufzeit deiner main sind alle Aus der dll exportierten symbole verfügbar, und Du kannst Klassen aus der dll instanzieren, wie als waeren sie in der statischen lib ... also aufn stack und per new ...
Nachteil, du brauchst zu der dll compatible compilereinstellungen. Da gegen eine lib linkst, sowieso vorraussetzung.
richtig dynamisches linken:
geht mit so erweiterungs-dlls wie oben beschrieben nicht.
Braucht man C- Kompatiblitaet, z.b. fuer andere Programmiersprachen als C++, sind klassen eh tabu
fuer c++ klassen/Interfaces gelten wiederum eigene Regeln dann. moglichst klassen bauen, die so wenig wie möglich Symbole definieren, sondern nur symbole referenzieren, und wenig anforderungen an die stellen. -> am besten nur 100% abstrakte klassen. die exportieren nur Methoden, und ne vtable. Absolut toedlich sind templates an der Stelle.
Klassen instanzierung muss dann auch ueber das interface geregelt werden, also Holder ist genau definiert, und oft gibt es dann craete und release methoden im dll-Interface fuer die klassen.
Ciao ...
Wenn Lib(statsche bibs) pfade nicht richtig gesetzt sind, und du linkst trotzdem gegen die lib, die er dann natuerlich nicht findet, hagelt es linker-Fehler. Beim VS compiler ziemlich genaue sogar, ala "konnte Link-Target nicht finden ... "
zu 2.
gibt halt mehrere Wege.
der M$ quasi statische Weg, dlls zu nutzen (meist als MFC Erweiterungs-dlls angepriesen):
du linkst eine statische lib, die laed die dll auch im pre-main code. d.h. zur laufzeit deiner main sind alle Aus der dll exportierten symbole verfügbar, und Du kannst Klassen aus der dll instanzieren, wie als waeren sie in der statischen lib ... also aufn stack und per new ...
Nachteil, du brauchst zu der dll compatible compilereinstellungen. Da gegen eine lib linkst, sowieso vorraussetzung.
richtig dynamisches linken:
geht mit so erweiterungs-dlls wie oben beschrieben nicht.
Braucht man C- Kompatiblitaet, z.b. fuer andere Programmiersprachen als C++, sind klassen eh tabu
fuer c++ klassen/Interfaces gelten wiederum eigene Regeln dann. moglichst klassen bauen, die so wenig wie möglich Symbole definieren, sondern nur symbole referenzieren, und wenig anforderungen an die stellen. -> am besten nur 100% abstrakte klassen. die exportieren nur Methoden, und ne vtable. Absolut toedlich sind templates an der Stelle.
Klassen instanzierung muss dann auch ueber das interface geregelt werden, also Holder ist genau definiert, und oft gibt es dann craete und release methoden im dll-Interface fuer die klassen.
Ciao ...