Thread: sharing varibles with DLLs

pass them in via dll function

typically you have a class or a struct that you can do this with. Think about windows API functions. You pass a pointer to some big structure in for a window class or bitmapinfo.

I'm not sure what the variables in question are. There may be a better way to do what you are doing. Generally, global is evil when it comes to variables, and this is especially true across DLL boundaries.

even in C you want structure. Scattered globals don't really reflect structure in your architecture. But again, it depends on the particulars. Grouping things together in an appropriate way into structs is not going to decrease readability. It will more likely improve it.

Not one big struct full of all your globals.

Perhaps you should spend some time thinking about the interface between the executable and it's DLLs.

Rather than trying to figure out how to get "a whole mess of global variables" from one side to another.

That you have "a whole mess of global variables" is a problem in itself.

ok...let's explain in depth my (superior ) coding style. I use VisualC++. I'm coding in a C-style C++...er...procedural programming...but I embed functions and data logically correlated in namespaces:

Code:

namespace
{
    namespace Class
    {
         namespace Win
         {
              ...
         }
         namespace Sys
         {
              ...
         }
         namespace Mem
         {
              ...
         }
         namespace Log
         {
              ...
         }
         ...
    }
    namespace Media
    {
         namespace Graphic
         {
              ...
              namespace Mgr
              {
                   ...
              }
         }
         namespace Sound
         {
              ...
              ...
         }
    }
}
...

as you can see I have a very complicated and depth "objects" diagram. Every namespace has its own functions and variables. This diagram it's declared in multiple header files, not in a big one. Each header adds its own namespace. The wonder of this method is that I don't have to necessarily write

Code:

mytype Class::Mem::Init()
{
     Media::Graphic::Mgr::LoadMesh();
}

I can simply write

Code:

mytype Mem::Init()
{
    LoadMesh();
}

So this coding style let me write faster and keeps clarity in code structure. It's like using classes with all the member functions and data declared static. I don't need more instances of the Mem or Log "class". I only need one. That's why I'm not using OOP, tough I use C++

Do you think that's not a good design?

Anyway I've already developed the interface for the DLLs...but as you see I have a framework to manage memory, system, logging ecc. I would like to use that framework inside the DLL projects too...

For example I would like to have a DLL for DirectSound, another for OpenAl...The interface for initialization, send of audio buffer, finalization ecc. it's already done...but I can't use my memory manager or log manager from the DLL.