Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I found this to be such an interesting question that I took the time to write an extensive tutorial on how to use DLL's to share data among multiple DLLs (either implicitly, or explicitly linked) but also make sure the data is not shared among separate processes of the same executable file.</p> <p>You can find the full article here: <a href="http://3dgep.com/?p=1759" rel="nofollow">http://3dgep.com/?p=1759</a></p> <hr> <p>A solution to this problem that I found to work quite well is to create a "common" or "shared" dll that defines all the data and methods that you want to share across multiple DLL's (but not shared among processes).</p> <p>Let's suppose you want to define a singleton class that can be accessed from the main application code (the EXE) but you also want to access the singleton instance in shared (either implicitly or explicitly linked DLL). First, you would need to declare the singleton class in the "common" DLL:</p> <pre><code>// Export the class when compiling the DLL, // otherwise import the class when using the DLL. class __declspec(dllexport) MySingleton { public: static MySingleton&amp; Instance(); }; </code></pre> <p>When compiling the CommonDLL project, you have to export the class declaratoin by decorating the class with <code>__declspec(dllexport)</code> and when you are using the DLL (in the application for example), the class definition needs to be imported by decorating the class with <code>__declspec(dllimport)</code>.</p> <p>When exporting a class by decorating the class with the <code>__declspec(dllexport)</code> specifier, all of the class's methods and data (even private data) are exported from the DLL and usable by any DLL or EXE that implicitly links to the common DLL.</p> <p>The definition of the MySingleton class might look something like this:</p> <pre><code>MySingleton&amp; MySingleton::Instance() { static MySingleton instance; return instance; } </code></pre> <p>When compiling the common dll, two files will be produced:</p> <ol> <li>The <strong>Common.DLL</strong> file which is the shared library that defines the mehthods and data exported used by the DLL.</li> <li>The <strong>Common.LIB</strong> file which declares stubs for the methods and members exported from the DLL.</li> </ol> <p>If you link you application against the exported LIB file, then the DLL file will be implicitly linked at runtime (as long as the DLL file is found in the DLL search paths) and you will have access to the singleton defined in the CommonDLL.DLL file.</p> <p>Also, any shared library (plug-ins for example) that also links against the CommonDLL.LIB file will have access to the same singleton instances when dynamically loaded by the application.</p> <p>For a full explanation of this solution including a source code sample, check-out the following article I posted titled "Using Dynamic Link Libraries (DLL) to Create Plug-Ins":</p> <p><a href="http://3dgep.com/?p=1759" rel="nofollow">http://3dgep.com/?p=1759</a></p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload