<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[DLL Fragen]]></title><description><![CDATA[<p>Hi</p>
<p>Ich versuche mich gerade an DLLs und habe da ein paar Fragen, zur exakten Funktionsweise. Grundsätzlich kann ich DLLs kompilieren und dynamisch laden (statisch sowieso).</p>
<p>Die Frage ist nun folgende: Ich will eine DLL dynamisch zur Laufzeit laden (wie nen Plugin). Allerdings habe ich ein paar Klassen, die nun sowohl vom Hauptprogramm, als auch von der DLL aus verwendet werden sollen, die über statische Variablen und Funktionen verfügen. Nach meinem ersten Test erscheint es so, als würde für die DLL und die EXE der statische Speicher der Klasse dupliziert, wodurch keine &quot;Kommunikation&quot; darüber zwischen DLL und EXE möglich ist.</p>
<p>Ehrlich gesagt wundert mich das nicht, aber ich suche halt doch nach einem Weg, dass statische Klassenvariablen tatsächlich nur einmal vorhanden sind und somit DLL und EXE exakt dieselben Daten manipulieren.</p>
<p>Da meine Klasse nun selbst in einer statischen Bibliothek untergebracht ist, hab ich mal ausprobiert diese Bibliothek als &quot;Multithreaded-DLL&quot; zu kompilieren (was bei VS 2005 sowieso als Standard für statische Bibliotheken eingestellt ist).</p>
<p>Ich hatte nun gehofft, dass wenn ich alle Bibliotheken als &quot;Multithreaded-DLL&quot; kompiliere, es vielleicht funktioniert wie erhofft. Allerdings kann ich die tatsächliche DLL nur &quot;Multithreaded&quot; kompilieren. Wenn ich es mit &quot;-DLL&quot; Anhängsel versuche, bekomme ich gut 20 Fehler a la</p>
<p>libcmt.lib(printf.obj) : error LNK2005: _printf ist bereits in MSVCRT.lib(MSVCR80.dll) definiert.</p>
<p>Erstens frage ich mich jetzt, was ich falsch mache, zweitens, ob mein Vorhaben so überhaupt umsetzbar ist. Kann mir also jemand sagen, ob es überhaupt möglich ist, dass die dynamisch geladene DLL auf die gleichen statische Daten einer Klasse zugreift, auf die auch die EXE zugreift? Wenn ja, wie?</p>
<p>Vielen Danke,<br />
Jan.</p>
]]></description><link>https://www.c-plusplus.net/forum/topic/153145/dll-fragen</link><generator>RSS for Node</generator><lastBuildDate>Wed, 22 Jul 2026 22:34:15 GMT</lastBuildDate><atom:link href="https://www.c-plusplus.net/forum/topic/153145.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 13 Jul 2006 10:59:51 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to DLL Fragen on Thu, 13 Jul 2006 10:59:51 GMT]]></title><description><![CDATA[<p>Hi</p>
<p>Ich versuche mich gerade an DLLs und habe da ein paar Fragen, zur exakten Funktionsweise. Grundsätzlich kann ich DLLs kompilieren und dynamisch laden (statisch sowieso).</p>
<p>Die Frage ist nun folgende: Ich will eine DLL dynamisch zur Laufzeit laden (wie nen Plugin). Allerdings habe ich ein paar Klassen, die nun sowohl vom Hauptprogramm, als auch von der DLL aus verwendet werden sollen, die über statische Variablen und Funktionen verfügen. Nach meinem ersten Test erscheint es so, als würde für die DLL und die EXE der statische Speicher der Klasse dupliziert, wodurch keine &quot;Kommunikation&quot; darüber zwischen DLL und EXE möglich ist.</p>
<p>Ehrlich gesagt wundert mich das nicht, aber ich suche halt doch nach einem Weg, dass statische Klassenvariablen tatsächlich nur einmal vorhanden sind und somit DLL und EXE exakt dieselben Daten manipulieren.</p>
<p>Da meine Klasse nun selbst in einer statischen Bibliothek untergebracht ist, hab ich mal ausprobiert diese Bibliothek als &quot;Multithreaded-DLL&quot; zu kompilieren (was bei VS 2005 sowieso als Standard für statische Bibliotheken eingestellt ist).</p>
<p>Ich hatte nun gehofft, dass wenn ich alle Bibliotheken als &quot;Multithreaded-DLL&quot; kompiliere, es vielleicht funktioniert wie erhofft. Allerdings kann ich die tatsächliche DLL nur &quot;Multithreaded&quot; kompilieren. Wenn ich es mit &quot;-DLL&quot; Anhängsel versuche, bekomme ich gut 20 Fehler a la</p>
<p>libcmt.lib(printf.obj) : error LNK2005: _printf ist bereits in MSVCRT.lib(MSVCR80.dll) definiert.</p>
<p>Erstens frage ich mich jetzt, was ich falsch mache, zweitens, ob mein Vorhaben so überhaupt umsetzbar ist. Kann mir also jemand sagen, ob es überhaupt möglich ist, dass die dynamisch geladene DLL auf die gleichen statische Daten einer Klasse zugreift, auf die auch die EXE zugreift? Wenn ja, wie?</p>
<p>Vielen Danke,<br />
Jan.</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1097033</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1097033</guid><dc:creator><![CDATA[Jan57]]></dc:creator><pubDate>Thu, 13 Jul 2006 10:59:51 GMT</pubDate></item><item><title><![CDATA[Reply to DLL Fragen on Thu, 13 Jul 2006 11:05:57 GMT]]></title><description><![CDATA[<p>Manipuliere einfach den Konstruktion &quot;x69\x7a\xa8\xa1&quot; der DLL<br />
in Grobfunktion daher wird kein konsequentes Zusammenspiel mehr<br />
ausgedrückt!</p>
<p>*Ranner*</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1097036</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1097036</guid><dc:creator><![CDATA[**Ranner**]]></dc:creator><pubDate>Thu, 13 Jul 2006 11:05:57 GMT</pubDate></item><item><title><![CDATA[Reply to DLL Fragen on Thu, 13 Jul 2006 11:12:27 GMT]]></title><description><![CDATA[<p>1. Klassen lassen sich nicht dynamisch aus einer DLL laden<br />
2. Du linkst Deine DLL vermutlich noch mit einer anderen LIB und diese verwendet ein anderes CRT-Model (also statisch anstelle von DLL); alle LIBs/Projekte, die in einer DLL (oder auch EXE) landen *müssen* mit *der selber* Version und Einstellung der CRT erstellt werden<br />
3. Wenn Du CRT/MFC/ATL Dinge zwischen der DLL und der EXE austauscht, so *muss* auch die EXE und DLL mit den gleichen CRT-Einstellungen erstellt werden<br />
4. Statische Variablen in einer DLL gibt es logischerweise nur einmal in dem Prozess</p>
]]></description><link>https://www.c-plusplus.net/forum/post/1097044</link><guid isPermaLink="true">https://www.c-plusplus.net/forum/post/1097044</guid><dc:creator><![CDATA[Jochen Kalmbach]]></dc:creator><pubDate>Thu, 13 Jul 2006 11:12:27 GMT</pubDate></item></channel></rss>