/MT und geteilte Laufzeitumgebungen

hustbaer

Nexus schrieb:

Übrigens, ist Code in der .cpp überhaupt komplett sicher (Linkzeit-Codegenerierung)?

Ja, ist er.
Derzeit zumindest.

ps:
Das mit dllexport/dllimport und inline steht hier:
http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx
Da steht allerdings nix vonwegen compilergenerierten Funktionen. Ich gehe aber davon aus dass die gleichen Regeln gelten wie bei inline Funktionen.

Nexus schrieb:

Wenn man also sicher gehen will, dass der Code in der .dll bleibt, muss man ihn in die .cpp schreiben. Wird folglich auf massivstes Boilerplate-Coden hinauslaufen, da man jeweils schön die Grossen Drei definieren darf. Etwas, das ich seit kopierbaren Smart-Pointern fast immer vermieden habe...

Ich finde, peinlichst genau darauf zu achten, dass kein Code die DLL verlässt ist sogar der einzig gangbare Weg. Man (bzw zumindest ich) benutzt ja gerade DLLs um portable Module zu haben, die man "überall" einsetzen kann. Das bedeuetet auch, dass man die DLLs mit anderen Compilern verwendet, etc. Sobald da einem ein inline rausleaken würde, wäre es damit vorbei. IMHO sollte man daher auch darauf achten, nicht ganze Klassen zu exportieren. Macht man das doch, baut also eine unportable DLL, kann man sich den ganzen Aufwand auch sparen, die DLL als LIB erstellen und diese dann halt zu seinem Projekt dazulinken.

Nexus

hustbaer schrieb:

Das mit dllexport/dllimport und inline steht hier:
http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx

Dort steht doch "You can define as inline a function with the dllexport attribute. In this case, the function is always instantiated and exported"... Also hängt es doch nicht davon ab, ob der Compiler Inlining für wichtig hält? Oder was verstehe ich falsch?

Morle schrieb:

Man (bzw zumindest ich) benutzt ja gerade DLLs um portable Module zu haben, die man "überall" einsetzen kann. Das bedeuetet auch, dass man die DLLs mit anderen Compilern verwendet, etc.

Ich dachte, das C++ ABI wäre überall unterschiedlich (zum Teil schon bei verschiedenen Versionen des selben Compilers), daher müsste man bei solchen Vorhaben auf C-Schnittstellen zurückgreifen.

Jochen Kalmbach

Nexus schrieb:

Ich dachte, das C++ ABI wäre überall unterschiedlich (zum Teil schon bei verschiedenen Versionen des selben Compilers), daher müsste man bei solchen Vorhaben auf C-Schnittstellen zurückgreifen.

Genau. Wenn Du portabel bleiben willst, darfst Du in der Schnittstelle nur simple POD Typen verwenden und immer eine DLL zur Verfügung stellen.
Siehe WinAPI...

hustbaer

Nexus schrieb:

hustbaer schrieb:

Das mit dllexport/dllimport und inline steht hier:
http://msdn.microsoft.com/en-us/library/xa0d9ste.aspx

Dort steht doch "You can define as inline a function with the dllexport attribute. In this case, the function is always instantiated and exported"... Also hängt es doch nicht davon ab, ob der Compiler Inlining für wichtig hält? Oder was verstehe ich falsch?

Oh boy.
Natürlich wird die immer in der DLL instanziert und exportiert. Muss ja. Was exportiert wird ist bloss leider vollkommen egal, interessant ist nur was importiert wird.

Wenn du 1.5 Sätze weiter gelesen hättest...

You can also define as inline a function declared with the dllimport attribute. In this case, the function can be expanded (subject to /Ob specifications), but never instantiated.
...
Exercise care when providing imported inline functions. For example, if you update the DLL, don't assume that the client will use the changed version of the DLL. To ensure that you are loading the proper version of the DLL, rebuild the DLL's client as well.

Also genau was ich geschrieben habe: die Funktion kann dennoch inline expandiert werden, nur wird sie nie instanziert.

hustbaer

Morle schrieb:

Macht man das doch, baut also eine unportable DLL, kann man sich den ganzen Aufwand auch sparen, die DLL als LIB erstellen und diese dann halt zu seinem Projekt dazulinken.

Weisst du, Freund Morle, es gibt auch noch andere gute Gründe dafür DLLs zu verwenden.

Martin Richter

hustbaer schrieb:

Morle schrieb:

Macht man das doch, baut also eine unportable DLL, kann man sich den ganzen Aufwand auch sparen, die DLL als LIB erstellen und diese dann halt zu seinem Projekt dazulinken.

Weisst du, Freund Morle, es gibt auch noch andere gute Gründe dafür DLLs zu verwenden.

Jo Zum Beispiel, wenn 10 Programme, die selbe Garif-Library, die selbe Packer-Lib, die gleiche statistische und matheamatische Bibliothek verwenden.
Alle Exes stammen immer aus einem Guß mit den DLLs. Das spart aber immens Spiecher, wenn 10 dieser Proezesse gleichzeitig laufen, denn die DLLs sind dann zehnmal genutzt aber nur einmal im Speicher!

Zudem ist der Pflegeaufwand geringer und das Setup auch. Ebenso werden Servicepacks einfacher.

Keine dieser DLLs hat pure POD Schnittstellen.

Nexus

@hustbaer, ich habe den ganzen Text gelesen, allerdings habe ich den dllimport -Teil falsch interpretiert. Danke für die Erklärung, ist aber dennoch kein Grund zum Aufregen

Martin Richter schrieb:

hustbaer schrieb:

Morle schrieb:

Macht man das doch, baut also eine unportable DLL, kann man sich den ganzen Aufwand auch sparen, die DLL als LIB erstellen und diese dann halt zu seinem Projekt dazulinken.

Weisst du, Freund Morle, es gibt auch noch andere gute Gründe dafür DLLs zu verwenden.

Jo Zum Beispiel, wenn 10 Programme, die selbe Garif-Library, die selbe Packer-Lib, die gleiche statistische und matheamatische Bibliothek verwenden.
Alle Exes stammen immer aus einem Guß mit den DLLs.

Genau. Gibts hier auch. Aus einem Guß heisst hier, dass die DLL in der Projektgruppe als Abhängigkeit der EXE mit drin ist. Hat zumindest fürs Kompilieren keinen Vorteil

Das spart aber immens Spiecher, wenn 10 dieser Proezesse gleichzeitig laufen, denn die DLLs sind dann zehnmal genutzt aber nur einmal im Speicher!

Zudem ist der Pflegeaufwand geringer und das Setup auch. Ebenso werden Servicepacks einfacher.

Speichersparen unterschreibe ich sofort. Ist IMHO bei Gigabytes von Arbeitsspeicher nicht mehr ganz so wichtig. Wichtiger finde ich den Pflegeaufwand, und da kann ich nicht zustimmen: Denn aus einem Guß heisst, ich muss aufpassen, wer im Team was kompiliert, etc. Durch menschliche Fehler kann es vorgekommen, dass jemand seine Compileroptionen verändert und dadurch solche DLLs sofort inkompatibel werden.

Daher habe ich hier für mich selbst eine Faustregel, dass es eine LIB wird, sofern die DLL in der selben Projektgruppe als Abhängigkeit zur EXE definiert wäre.

Martin Richter

Sicher hat es für das Kompilieren Vorteile.
Es dauert nicht so lange. Die EXE ist schneller gelinkt.
Der Pflegeaufwand bzgl. Hotfixes ist geringer.

Wenn ich 10 15MB Projekte eine Lib staisch einlinke, wobei die hälfte des Codes aus DLLs stammen könnte macht dies auch im Entwicklungszyklus eine Beschleunigung aus.
Zudem bleiben die Entwicklungseinheiten auch besser abgegrenzt.

Das mit dem Compiler-Schalter kann ich nicht nachvollziehen.

Im Team arbeiten wir mit dem TFS. Man kann also nicht "einfach was an den Projekteinstellungen ändern". Ausgeliefert wird nur, was aus dem Build-Server läuft. Nicht was von den Entwicklungsrechnern kommt.

Aber jeder Entwickler hat möglichen Zugriff auf alle Teil Projekte/DLLs.