Welche Vorteile/Nachteile haben DLLs, gibt es Tuts zur Programmierung?
Denn ich würde meine Verschlüsselung gern in einer DLL realisieren und benutzen, doch habe keine Ahnung wie das geht...

THX

Wenn man sowiso nur vor hat das ganze in einem Projekt zu benutzen, dann würd ich das einfach nur in eine eigene cpp und dazugehörigem header packen.

wieso nicht einfach die cpp/header in ein anderes Projekt einfügen?

Krux schrieb:

Wenn man sowiso nur vor hat das ganze in einem Projekt zu benutzen, dann würd ich das einfach nur in eine eigene cpp und dazugehörigem header packen.

wieso nicht einfach die cpp/header in ein anderes Projekt einfügen?

Weil man dann bei einer kleinen Änderung der .cpp alle Projekte neu kompilieren müsste...

wieso nicht einfach die cpp/header in ein anderes Projekt einfügen?

Weil man dann bei einer kleinen Änderung der .cpp alle Projekte neu kompilieren müsste...[/quote]
nein, musst du nicht. wenn deine anderen projekte fertig sind, musst du nichts ändern. wenn du an der cpp allerdings doch was ändern musst, dann ist es richtig, direkt die anderen projekte neu zu compilieren, weil bugfixes halt gemacht werden müssen ;). Wenn deine anderen projekte eh noch nicht fertig sind, dann ist es eh wurscht, compilieren musst sie so oder so nochmal.

dem gegenüber stehen halt die nachteile der dlls:

1. ätzende Syntax
2. unübersichtlichkeit
3. template probleme
4. austauschbarkeit zwischen compilern
5. windows spezifisch

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Nimm doch .NET oder Shared Libraries!

ich würde sagen, unabhängig von der Sprache/Umgebung hast Du eigentlich immer die Vor- und Nachteile der "Kopplung":
+ Spart Platz/Code, ReUse
- Verwaltungsoverhead, Kollisionen

Ich weiß noch, wie damals in Windows DLLs eingeführt wurden und es hieß, ALLES müsste nun in DLLs liegen ... inzwischen weiß man glücklicherweise, dass es (wie jedes Werkezeug, jede Technik) mal mehr mal weniger geeignet ist.

Gruß,

Simon2.

http://members.inode.at/anton.zechner/az/index.html

Sind auch noch andere nette sachen dabei

Und was glaubst du was eine Shared LIB ist? Unter Linux heben diese die Endung *.so
für Shared Object und unter Windows eben *.dll

Unix-Tom kennt den Unterschied zwischen Linux Shared Libraries und Windows DLLs nicht? In Shared Libraries gelten beide von mir äääh Skeptiker genannten Einschränkungen nicht.

Dynamische Biblioteken wie die Dlls haben den Vorteil, dass sie eben dynamisch geladen werde. => man kann sieselbst während das Programm läuft austauschen,...

Wenn eine DLL benutz wird, kann ich sie nicht mal löschen. Wie dann austauschen, wenn das Programm läuft?

Auch eine "Bibliothek" in Linux kann man Linken und sie wird beim Programmstart geladen. Genauso wie eine DLL.
Genauso kann man eine DLL dynamisch laden genauso wie eine *.so.

Das ist ja wohl bekannt.

Unix-Tom schrieb:

Ich kenne sehr wohl beide.

Aber offensichtlich nicht gut genug.

Unix-Tom schrieb:

DLL`s unter Windows werden geshared wenn man die gleiche DLL im selben Ordner aufruft.

Darum gehts doch nicht. Es geht doch vor allem darum, dass man nicht Pointerownership zwischen DLLs transferieren kann. Und die Sache mit den Threads / anderen DLLs.

Diese Einschränkungen haben mich so angekotzt, dass ich nichtmal versucht habe, mein Plugin-System auf Windows zu portieren.

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. DLLs können dafür nichts. Adobe hat keine Probleme mit Plugin-Systemen und DLLs

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.

Kenner der Scene schrieb:

DLLs können dafür nichts.

Doch.

Kenner der Scene schrieb:

Adobe hat keine Probleme mit Plugin-Systemen und DLLs

Die verwenden mit Sicherheit kein volles C++ dafür.

Bei einem Unreg mach ich mir mal nicht die Mühe, alles zu belegen.

Die verwenden mit Sicherheit kein volles C++ dafür.

Hier gehts doch um DLLs und nicht um C++. DLL Einschränkungen gelten doch auch für andere Sprachen...

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.

(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?

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".

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.