static variable vs. DLL

This is a discussion on static variable vs. DLL within the C++ Programming forums, part of the General Programming Boards category; Hi, in Windows (XP at least) a static declared variable seems not to be consistent over DLL boundaries. So for ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    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!

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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!

  4. #4
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Yes. The DLL will be loaded only once, so only one copy of the C library will be present.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by CornedBee View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    For each process, yes. So? Handles are process-specific anyway.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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:

    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!

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,792
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,792
    Quote Originally Posted by CornedBee View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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++.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #12
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Static variable usage
    By shwetha_siddu in forum C Programming
    Replies: 1
    Last Post: 04-02-2009, 12:33 AM
  2. Problem with Free.
    By chakra in forum C Programming
    Replies: 9
    Last Post: 12-15-2008, 10:20 AM
  3. Seg Fault in Compare Function
    By tytelizgal in forum C Programming
    Replies: 1
    Last Post: 10-25-2008, 03:06 PM
  4. Replies: 6
    Last Post: 12-13-2007, 07:20 PM
  5. DLL compiling question
    By Noose in forum Windows Programming
    Replies: 2
    Last Post: 12-16-2004, 06:16 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21