Klassen aus DLL nutzen

Hallo!

Ich würde gerne einige Klassen meiner Anwendung in DLLs auslagern, um kleine übersichtliche Pakete zu scnüren und meinen Code besser zu "portionieren".

Es gibt MFC Extensions wo man mit AFX_EXT_CLASS seine Klasse definiert. Jedoch schaut das dann im Dependency Walker recht wüst aus, zudem fänd ich es nett wenn man nicht die KLassennamen sehen würde.

Gibt es eine andere Möglichkeit hier seine Klassen in DLLs zu stecken und lediglich die Header-Dateien "einzubinden"?

Bei den MFC geht es doch aus und die nutzen kein AFX_EXT_CLASS.

hustbaer

Jedoch schaut das dann im Dependency Walker recht wüst aus, zudem fänd ich es nett wenn man nicht die KLassennamen sehen würde.

Boo-hoo!

Gibt es eine andere Möglichkeit hier seine Klassen in DLLs zu stecken und lediglich die Header-Dateien "einzubinden"?

Ja. Schreib ein .def File, damit kannst du "by ordinal" exportieren.

Da darfst du dann alle dekorierten Funktionsnamen reinschreiben die du exportiert haben möchtest. Viel Spass.

Martin Richter

Sicher benutzt die MFC genau das selbe Verfahren.
Die Klassen stekcen in Headern und die DLL exportert diese. Wieso siehst Du hier einen Unterschied zu extension DLLs? Genaugenommen ist die MFC selbst eine Extension DLL, sie behandelt sich selbst und die Sprach DLLs genau so.

Im Dependency Walker siehst Du eben die gemangelten Symbolnamen. Das macht een der C++ Compiler so. Was stört Dich daran?

Greif doch einfach auf Interfaceklassen zurück, so wie das COM macht.
Exportiere in der DLL nur eine Faktory und in der Header stehten nur Interfaces (pure virtuelle Klassen). Die Factory liefert Dir einen Zeiger auf die Klasse.

hustbaer schrieb:

Boo-hoo!

hustbaer schrieb:

Da darfst du dann alle dekorierten Funktionsnamen reinschreiben die du exportiert haben möchtest. Viel Spass.

Wie genau würde das aussehen? In etwa so?

LIBRARY MyDll
EXPORTS
CMyClass       @1
CMySecondClass @2

Martin Richter schrieb:

Sicher benutzt die MFC genau das selbe Verfahren.
Die Klassen stekcen in Headern und die DLL exportert diese. Wieso siehst Du hier einen Unterschied zu extension DLLs?

Weil ich dachte, dass extendions DLLs immer diesen hässlichen Exporte haben. Eigentlich reine Unwissenheit.

Martin Richter schrieb:

Im Dependency Walker siehst Du eben die gemangelten Symbolnamen. Das macht een der C++ Compiler so. Was stört Dich daran?

Es sieht irgendwie unsauber aus. Die MFC Dlls sehen im Dependency Walker "schicker" aus.
Warum nutzt denn die MFC dann def-Dateien?

Martin Richter schrieb:

Greif doch einfach auf Interfaceklassen zurück, so wie das COM macht. Exportiere in der DLL nur eine Faktory und in der Header stehten nur Interfaces (pure virtuelle Klassen). Die Factory liefert Dir einen Zeiger auf die Klasse.

Ganz genau verstanden habe ich das nicht. Aber mir scheint, dass es den Code und die Lesbarkeit/Verständnis unnötig verkompliziert als die "reinen" Klassen direkt zu nutzen.

Martin Richter

ordinales Linkes ist schenller, aber eben extrem mühsam.
Da kann man sich nur die Mühe machen, wenn sich die Klassen so gut wie nie ändern (wie bei der MFC).

Martin Richter schrieb:

ordinales Linkes ist schenller, aber eben extrem mühsam.
Da kann man sich nur die Mühe machen, wenn sich die Klassen so gut wie nie ändern (wie bei der MFC).

Klassennamen "sollten" sich doch auch "nie" ändern.
Einziger Grund nach Refactoring, weil ein besserer Name gefunden wurde.

Die Arbeit wäre sehr überschaubar, da ich in die DLLs keine 100 Klassen stecken würde, sondern nur ein paar vielleicht 10-20.

hustbaer

Klaas123 schrieb:

hustbaer schrieb:

Da darfst du dann alle dekorierten Funktionsnamen reinschreiben die du exportiert haben möchtest. Viel Spass.

Wie genau würde das aussehen? In etwa so?
LIBRARY MyDll
EXPORTS
CMyClass       @1
CMySecondClass @2

Nö, eher so:

LIBRARY PFUISPINNE
EXPORTS
    ?decoration@?$PKCS_DigestDecoration@VSHA224@CryptoPP@@@CryptoPP@@2QBEB    @1 NONAME
    ?destroy@?$AllocatorBase@E@CryptoPP@@QAEXPAE@Z                            @2 NONAME
    ?VerifyPrime@CryptoPP@@YA_NAAVRandomNumberGenerator@1@ABVInteger@1@I@Z    @3 NONAME
    ?VerifyMessageRepresentative@PK_DeterministicSignatureMessageEncodingMethod@CryptoPP@@UBE_NAAVHashTransformation@2@U?$pair@PBEI@std@@_NPAEI@Z    @4 NONAME

Das sind bloss mal 4 beliebige dekorierte Namen aus der Crypto++ Library. Nicht dass du denkst ich will dich hier verarschen...

Und da du das nicht begriffen zu haben scheinst: alle Funktionen (=Memberfunktionen), nicht bloss ein paar Klassennamen. 10 Klassen mit je 10 Memberfunktionen -> 100 Einträge.
Kurz: vergiss es, und finde dich damit ab, dass da einfach die Namen drinstehen.

hustbaer schrieb:

Und da du das nicht begriffen zu haben scheinst: alle Funktionen (=Memberfunktionen), nicht bloss ein paar Klassennamen. 10 Klassen mit je 10 Memberfunktionen -> 100 Einträge.
Kurz: vergiss es, und finde dich damit ab, dass da einfach die Namen drinstehen.

Hmpf, da ist was dran...

Martin Richter

Klaas123 schrieb:

Klassennamen "sollten" sich doch auch "nie" ändern.
Einziger Grund nach Refactoring, weil ein besserer Name gefunden wurde.

Die Arbeit wäre sehr überschaubar, da ich in die DLLs keine 100 Klassen stecken würde, sondern nur ein paar vielleicht 10-20.

Es geht mir doch nicht um Namen. Du müsstest für jede Funktion deren Signatur sich ändert eingreifen..., jede neue Funktion, jede Funktion, die entfernt wird.

100 Klassen x 15 Memberfkt. im Schnitt (wenns es langt) = 1500 Einträge die zu verwalten sind.

Horror...