static variable vs. DLL

Hi,

in Windows (XP at least) a static declared variable seems not to be consistent over DLL boundaries. So for a static variable declared inside the application &(my_static_var) called from the application returns an other address that called from inside a DLL-function.
Knowing that, I always avoided static variables in my windows apps which uses DLLs.

Unfortunately now I have to integrate a static linked (c-)library which internally uses a static declared variable to save a handle after an init-like library function is called. Because that handle is only valid inside one context (depending from where I called the init function inside the application or an DLL), my design is pretty broken.

Is there maybe any linker option or anything to change the default behavior, so all the DLLs as well as the main application uses the same memory for static variables?

Thank you in advance!

static as in global-level static? They're supposed to be local to the compilation unit, so of course they would have different addresses in the EXE and the DLL.

More importantly, if this C library is statically linked, the EXE and the DLL will both have entirely separate copies of it. Even normal globals would be separate.

If you can't make the C library itself dynamic, I think the only viable solution is to write a wrapper DLL that basically exposes the same interface, and just forwards all calls to its own copy of the static library.

Ups, I see, memory comes back online...file static variables are only visible from inside the compilation unit.
I had the same effect (different addresses for getInstance() from DLL and app) also for the meyers singleton (using a function level static object) some time ago, so I mixed that up.

Just to see If I got it right: If I use the dynamic wrapper approach you described and than link that resulting DLL to the main app and also to several other DLLs, will everybody "see" the same memory for the global static variables while indirectly accessing the c-library? It sounds a bit adventurous.
Thank you!

Yes. The DLL will be loaded only once, so only one copy of the C library will be present.

Quote:

---

Originally Posted by CornedBee

Yes. The DLL will be loaded only once, so only one copy of the C library will be present.

---

But variables are in the writable data area which is (as far as I understand) copied fresh for each process (or even thread?) - I've never really worked that much with this sort of concept, but I think that's how it works?

--
Mats

For each process, yes. So? Handles are process-specific anyway.

Hi,

I just wanted to confirm that building a DLL did solve the problem :)


To finally learn about the static keyword I've writte a little test using a static class member:

Code:

---

// dll_part.h
#pragma once

struct TestClass
{
        static int myStatic;
        void out();

};


// dll_part.cpp
#include "dll_part.h"
#include <iostream>

int TestClass::myStatic = 5;

void TestClass::out()
{
        std::cout << "Address of static member from DLL: " << &(TestClass::myStatic) << std::endl;
}




// dll_part.def
LIBRARY DLL_PART
EXPORTS
        ?myStatic@TestClass@@2HA
        ?out@TestClass@@QAEXXZ





// main.cpp
#include <iostream>
#include "dll_part.h"

int main()
{
        std::cout << "Address of static member from main app: "
              << &(TestClass::myStatic)
              << std::endl;  // call stack says: app_part.exe!main()  Line 6        C++
        TestClass tc;        // call stack says: dll_part.dll!TestClass::out()  Line 7        C++
        tc.out();
}

---

And the output is:

Quote:

---

c:\static_vs_dll_test\debug>app_part.exe
Address of static member from main app: 004111A9
Address of static member from DLL: 10018004

---

So is the reason for the different addresses a C++ rule or a windows-DLL-thing? In any case a reference to read about it would be highly appreciated.
Thank you!

While we're at the subject...
Does the .def file need to be:

Code:

---

// dll_part.def
LIBRARY DLL_PART
EXPORTS
        ?myStatic@TestClass@@2HA
        ?out@TestClass@@QAEXXZ

---

Or just

Code:

---

// dll_part.def
LIBRARY DLL_PART
EXPORTS
        myStatic
        out

---

Assuming they are functions. Classes and data can be exported by adding __declspec(dllexport/dllimport), though it only works within Visual Studio.

Careful: static on globals, locals and class members means different things.

The def file must contain the mangled names, or the compiler won't find them. But using declspec is probably the better way.


Oh, and it's a Windows thing, although the same problem can occur with *nix shared objects. Depends on the loader.

The next C++ standard might contain a few words on the subject, but the current one doesn't acknowledge the existence of DLLs.

Quote:

---

Originally Posted by CornedBee

The def file must contain the mangled names, or the compiler won't find them. But using declspec is probably the better way.

---

No, it works fine without mangled name for exporting C++ functions in Visual Studio. What I don't know is if it works in other compilers, if it's platform dependant, etc.

Well, def files themselves are a Win32 concept, so yes, it's platform-dependent. I don't know about other compilers, and I'm somewhat surprised that it works without the mangled name for VC++.

It seems that it works with un-mangled names in basic cases, but for overloaded functions or CTORs one need to use the mangled form.

http://msdn2.microsoft.com/en-us/lib...60(VS.60).aspx