For my project I often use DLLs to write modules so I can load only the needed ones at runtime. The problem is that have to use functions and variables that are inside the exe project from the DLL projects. What method could I use?
Thanks!
For my project I often use DLLs to write modules so I can load only the needed ones at runtime. The problem is that have to use functions and variables that are inside the exe project from the DLL projects. What method could I use?
Thanks!
pass them in via dll function
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
ok...but do I really have to make a copy of ALL the variables on every DLL project? There are not other ways?
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.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
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.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
I'm coding in C. I could make all my global variables inside a big structure (and that's not good for readibility) ...but they are declared in more than one source file. It would get really complicated to realize what you say...
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.
"You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter
well...that's ok...I'm could use structs then...
anyway I've found that VisualC++ supports the __declspec(dllimport) identifier. Could it be used for my purpose?
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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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
I can simply writeCode:mytype Class::Mem::Init() { Media::Graphic::Mgr::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++Code:mytype Mem::Init() { LoadMesh(); }
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.
Last edited by ZeroMemory; 11-06-2008 at 12:18 PM.
and of course void Bar; needs to be exported from the exeCode:// variable in the DLL that teh main exe needs to access _declspec(dllexport) void Foo; // variable that is in the main exe that the dll needs to access _declspec(dllimport) void Bar;
http://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx
ok...thanks abachler!
so do you know if it's better to use dllimport/dllexport or to use a structure for globals and then pass its pointer?