DLLs Vorteil/Nachtei/Tutorial?
-
Pointer Ownership ist kein Problem solange alle DLLs die selbe Heap Implementierung verwenden, die dann entweder selbst in einer DLL steht oder andere Mittel & Wege verwendet eben das zu ermöglichen.
(Die einfachste variante unter Windows ist den Process Heap zu verwenden, dann ist vollkommen egal wo new/delete/malloc/free implementiert sind und ob mehrere Kopien davon verwendet werden)Die Sache mit den globalen Konstruktoren ist etwas blöd, da muss ich Mr. N. Recht geben. Lässt sich aber normalerweise drum rum arbeiten.
-
hustbaer schrieb:
(Die einfachste variante unter Windows ist den Process Heap zu verwenden, dann ist vollkommen egal wo new/delete/malloc/free implementiert sind und ob mehrere Kopien davon verwendet werden)
Wie geht das? Warum sagt mir das keiner?
-
z.B. so:
HANDLE processHeap = GetProcessHeap(); // immer der selbe für einen Prozess, egal in welcher DLL size_t size = 1234; void* p = HeapAlloc(processHeap, 0, size); // 0: flags - siehe MSDN // ... BOOL rc = HeapFree(processHeap, 0, p); assert(rc);Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
p.S.: natürlich müssen alle new/delete/malloc/free Implementierungen *gleich* sein (nur dass der Code mehrfach dupliziert sein darf, da man den Process Heap als golbales Singleton verwendet), ich hoffe das war klar. DLLs die einfach irgendeine new/delete Implementierung verwenden (z.B. die vom VC6) kann man damit natürlich nicht "erschlagen".
-
hustbaer schrieb:
z.B. so:
HANDLE processHeap = GetProcessHeap(); // immer der selbe für einen Prozess, egal in welcher DLL size_t size = 1234; void* p = HeapAlloc(processHeap, 0, size); // 0: flags - siehe MSDN // ... BOOL rc = HeapFree(processHeap, 0, p); assert(rc);OK.
hustbaer schrieb:
Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
Es wäre absolute Bedingung. Viele Bibliotheken verwenden unüberschreibbar malloc/free bzw. new/delete.
-
Mr. N schrieb:
Kenner der Scene schrieb:
Mr. N schrieb:
Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.
Könnte auch daran liegen, dass dein "Plugin-System" ein grottenschlechtes Design hat.
Blödsinn.
Hochmut kommt kurz vor dem Fall. Wenn du noch nicht mal weißt wie man den Prozess-Heap anzapft und welche Auswirkungen das auf DLLs hat, solltest du nicht mit "Blödsinn" angeheult kommen, sondern dir ernsthafte Gedanken machen.
-
Mr. N schrieb:
hustbaer schrieb:
Die MSVC Runtimes können z.B. auch mit dem Process Heap arbeiten (dann kann man das eingebaute malloc/free/new/delete verwenden), bloss weiss ich im Moment nicht wie man die dazu überreden kann, bzw. ob das nicht sogar default ist bei MSVC 7.1 und 8. Müsste man mal gucken ob das dokumentiert ist bzw. einfach ausprobieren.
Es wäre absolute Bedingung. Viele Bibliotheken verwenden unüberschreibbar malloc/free bzw. new/delete.
Solange man diese Bibliotheken mit der DLL Runtime vom MSVC compiliert sollte das doch egal sein, oder?
Ich meine zig verschiedene DLLs die aber alle mit der selben DLL Runtime compiliert wurden kann man was new/malloc angeht *immer* mischen, egal wie das implementiert ist, da durch die Verwendung der DLL Runtime ja trotzdem immer der selbe Heap verwendet wird...
-
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
-
hustbaer schrieb:
Solange man diese Bibliotheken mit der DLL Runtime vom MSVC compiliert sollte das doch egal sein, oder?
Ich meine zig verschiedene DLLs die aber alle mit der selben DLL Runtime compiliert wurden kann man was new/malloc angeht *immer* mischen, egal wie das implementiert ist, da durch die Verwendung der DLL Runtime ja trotzdem immer der selbe Heap verwendet wird...Nun ja, ich habe darauf vertraut, dass derjenige, der von diesen Problemen erzählt hat, die Wahrheit spricht, dass eine MSVC-Runtime-DLL das Problem löst, wusste ich nicht.
Vielleicht habe ich ja nur einen Vorwand gesucht, nicht unter Windows programmieren zu müssen.
-
Mr. N schrieb:
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
Und wieso sollte man das. Du hast z.b. auch mich angegriffen das ich mich nicht auskenne. Man kann nicht austeilen und sich dann aufregen das man auch einsteckten muss.
-
Mr. N schrieb:
Vielleicht habe ich ja nur einen Vorwand gesucht, nicht unter Windows programmieren zu müssen.
Wäre schon möglich, du musst das natürlich am besten wissen
-
Unix-Tom schrieb:
Mr. N schrieb:
In NadrW sind Unregs ja schon verboten, wie wärs damit, sie auch hier zu verbieten?
Und wieso sollte man das. Du hast z.b. auch mich angegriffen das ich mich nicht auskenne. Man kann nicht austeilen und sich dann aufregen das man auch einsteckten muss.
Weil du behauptet hast, dass DLLs und Shared Libraries das selbe wären. Ich sah das (EDIT: meine Reaktion) eigentlich eher als Abwehrreaktion, weil du ohne echten Grund (außer deiner impliziten Vermutung, dass ich glaubte, das sei etwas grundlegend Unterschiedliches) behauptet hast, meine Unterscheidung sei falsch. (Wie sich herausgestellt hat, ist einer der beiden Punkte zwar umgehbar, aber die Unterschiede bleiben bestehen.)
Von einem Unreg hingegen, der nichts auch nur ansatzweise begründet, will ich mich nicht beleidigen lassen. Wäre dieser registriert gewesen, hätte ich anders reagiert.
-
OK, da scheine ich wohl auch noch was lernen zu müssen (bin aber nur Windows-User): was ist denn die Definition von Sharedlibs, so das sie sich von DLLs unterscheidet?
-
Mr. N schrieb:
Von einem Unreg hingegen, der nichts auch nur ansatzweise begründet, will ich mich nicht beleidigen lassen. Wäre dieser registriert gewesen, hätte ich anders reagiert.
Wo denn gibt es denn Beleidigung? Habe ich etwa gesagt: "Du Haufen?" Nö. Also Bitte, lass das weinen sein.
Ich sagte nur, dass es ein Designfehler ist, was ja auch sehr möglich ist, da du das mit dem Prozess-Heap nicht wusstest - welcher ja eigentlich elementar für Designs mit DLLs ist.
Aber jemand der so ein Ego hat wie du und von sich behauptet: "Die anderen sind es schuld, mein Design ist das Beste - Ever!" und von wegen: "Die machen das sicherlich nicht so!". Sorry, der zeugt nicht gerade von Kompetenz - vorallem da du auch noch Unix-Tom von der Seite ans Bein gepinkelt hast.
-
Aber so wie ich das seh, ist jeder Unreg für Mr. N direkt der Dreck des Forums.
-
Artchi schrieb:
OK, da scheine ich wohl auch noch was lernen zu müssen (bin aber nur Windows-User): was ist denn die Definition von Sharedlibs, so das sie sich von DLLs unterscheidet?
Achtung: Ich kenne nur ELF-SharedLibs.
DLLs werden bekanntlich indirekt gelinkt, über .libs. Soweit ich weiß ist eine DLL fast wie ein eigener Prozess, nur dass eben von außen über Namen und Nummer auf Funktionen zugegriffen werden kann. Sie haben ja auch ihren eigenen Heap. Beim Starten wird die DLLMain aufgerufen, die einige interessante Einschränkungen hat.
Shared Libraries werden direkt gelinkt. Beim Compilieren werden sie erstmal nur als Abhängigkeit eingetragen und es wird geprüft, ob alle Symbole vorhanden sind. Zur Runtime wird dann wirklich gelinkt. (Wobei das nur fast stimmt, man kann Symbole so markieren, dass sie schon vorher gelinkt werden und dann nach außen nicht sichtbar sind.) Eine Shared Library hat keinen eigenen Heap und beim Laden werden die Funktionen mit constructor-Attribut aufgerufen, umgekehrt beim Entladen die Funktionen mit destructor-Attribut, für diese gibt es keine schwerwiegenden Einschränkungen.
Shared Libraries haben noch ein paar interessante Anwendungsmöglichkeiten, die durch das Linken zur Laufzeit entstehen. So kann man zum Beispiel eine Shared Library preloaden um Funktionen aus anderen Bibliotheken zu ersetzen. Oder man kann eine Bibliothek mit dem Flag RTLD_GLOBAL händisch laden, dann können alle danach händisch geladenen Bibliotheken auf deren Symbole zugreifen. Und noch ein paar andere lustige Dinge.
Der größte Nachteil von Shared Libraries ist IMHO, dass man leicht in Versuchung gerät, mehr zu exportieren als nötig, da standardmäßig alle Symbole exportiert werden. Aber mit dem GCC-Flag -fvisibility=hidden kann man das umdrehen.
Alle Angaben ohne Gewähr.
Kenner der Scene schrieb:
Aber so wie ich das seh, ist jeder Unreg für Mr. N direkt der Dreck des Forums.
Ja, bis das Gegenteil bewiesen ist. Des weiteren ist ja der Punkt, dass ich keine Lust hatte, mein Design auf etwas so Eingeschränktes wie DLLs anzupassen.
-
Mr. N schrieb:
Ja, bis das Gegenteil bewiesen ist.
Sind wir ein "klein bisschen" rassistisch gegenüber Unregs? "Ja, bis das Gegenteil bewiesen ist." kommt mir irgendwie bekannt vor, ist aber ein paar Jahrzehnte her.
Mr. N schrieb:
dass ich keine Lust hatte, mein Design auf etwas so Eingeschränktes wie DLLs anzupassen.
DLLs sind nicht eingeschränkt nur dein Konzept mit ihnen umzugehen, ja ich weiß: Um dein Ego zu verteidigen kommt jetzt wieder Blödsinn und alle anderen sind es schuld. Ja ja, selbst die von Adobe, Microsoft, Novell, uvm. weil die mit DLLs richtig umgehen können.
-
Ach ja, wenn man fünf Anwendungen lädt, die die Shared Library libfoo.so laden, wird libfoo.so nur einmal physikalisch in den Speicher geladen (übrigens mit mmap, das natürlich fünfmal), nur die Tabelle mit den Funktionspositionen ist für jeden Prozess lokal.
-
Kenner der Scene schrieb:
Mr. N schrieb:
Ja, bis das Gegenteil bewiesen ist.
Sind wir ein "klein bisschen" rassistisch gegenüber Unregs? "Ja, bis das Gegenteil bewiesen ist." kommt mir irgendwie bekannt vor, ist aber ein paar Jahrzehnte her....
Guter Vergleich: "Unreg-Poster im C++-Forum" sind die "Juden von heute" !
Gibt doch nichts, was man mit einem Nazivergleich nicht noch unterbieten könnte.Großes Kino !
-
Dabei müssen DLLs aber nicht unbedingt gelinkt werden, man kann auch DLLs erst später nachladen. (Für plugIns etwa)
-
TheToast schrieb:
Dabei müssen DLLs aber nicht unbedingt gelinkt werden, man kann auch DLLs erst später nachladen. (Für plugIns etwa)
Ich dachte, DLLs werden überhaupt nicht gelinkt.
Klar, beim späteren Laden muss man die Funktionen aber alle händisch extrahieren, per GetProcAddress, oder etwa nicht? (Ist natürlich auch bei Shared Libraries so.)
