|
Prev: Port MFC CCriticalSection::CSingleLock to ACE or ??? (NEWBIE ALERT)
Next: How to call DLL file from Visual C++ 4.2?
From: malachy.moses on 1 May 2008 21:46 On May 1, 2:05 pm, "JD" <jdt_yo...(a)yahoo.com> wrote: > Hi, > > I know it sounds against the object oriented concept. Is it possible to > share a global variable among dlls? I am a OO faithful guy. However, in > some very rare situations, a globally shared variable among dlls is a good > solution to reduce complexity, if it's possible. > > Thanks. > JD If the DLLs are different DLLs (as opposed to a single DLL that needs to share data with other instances of itself that have been loaded by other applications), then perhaps an extra level of indirection would help. Create a new DLL whose sole purpose is to share global data. Then use one of the techniques described here (i.e., use either the data_seg pragma or use memory mapped files): "How do I share data in my DLL with an application or with other DLLs?" at http://msdn.microsoft.com/en-us/library/h90dkhs0(VS.80).aspx If the DLLs are not different, but rather there is a single DLL that shares data with other instances of itself, then there is no need for an extra level of indirection, and one of the above two techniques can be used directly.
From: Joseph M. Newcomer on 1 May 2008 22:54
Well, I'd come down on the side that this is a Really Bad Idea. But if you put the "global "variable in a DLL of its own, and provide set and get methods, it would solve the problem. The problem you are trying to solve is "I wish to have a common single definition point of a particular value which may change and I do not wish to have to enumerate all the clients that may need to know its new value". There are alternatives to implement this concept. Global variable is one, but putting exported variables in a DLL is tacky and somewhat perilous. Creating a singleton class in a separate DLL that manages the "global" state would be another. Having a private variable (a static variable) in a DLL with set and get methods would be another. Knowing if the "global" state is going to be common to all clients independent of thread context would be important, and if it could be multithreaded, and is other than a simple 32-bit scalar value, you will need to provide synchronization if it can be altered while other threads are accessing it. You may need to worry about memory barriers on some multiprocessors. Or you can declare that it can only be accessed by one thread. Note that you should not confuse a single implementation (global variable) with a solution to a problem. joe On Thu, 1 May 2008 14:05:36 -0700, "JD" <jdt_young(a)yahoo.com> wrote: >Hi, > >I know it sounds against the object oriented concept. Is it possible to >share a global variable among dlls? I am a OO faithful guy. However, in >some very rare situations, a globally shared variable among dlls is a good >solution to reduce complexity, if it's possible. > >Thanks. >JD > > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |