Pavel Vozenilek wrote:
A library named Shmem is being developed (quite mature, can be found in sandbox).
With this or similar library one could allocate small, uniquely named memory block and singleton infrastructures from each DLLs would (behind the curtain) use it.
Then there would be no need for separate Win32 interface.
I agree that shared memory is one way to solve this. Note however that this is a problem that is specific to DLLs on windows -- where the meaning of C++ writeable static variables is broken. This is AFAIK not an issue with any other dynamic libraries like .so files in unix/linux. It is important to limit the workaround to the windows environment. I have experienced problems with side-effects of this type of shared memory solution for singelton, where the negative side effect was on Solaris. I.e. they had used the workaround for this windows DLL "bug" in portable code for all platforms. Needless to say, this was very annoying since it was completely unnessesary. In addition it affected the stability of our clients code, I was not happy :-( So if this is the way you plan to fix the problen, make it a conditional compile for windows. By the way, a more general solution to win32 DLL writable static variables problem may be a nice little thing to add to Boost. It would be something that looks as much as possible like a static variable, and expand to it om all platforms except win32. I really dont like the smell of it, but it may be usefull if you have to write portable code. A real solution would be to stop using compiler/platform/tool combinations with this sort of problem; unless it is fixed (dream on). To me it is as simple as to say: the C++ programming language is not supported with DLLs on windows :-(. Windows DLLs a whole set of rules you need to follow to get the bennifits they do provide, some of these does not play well with efforts to create good portable C++ code. ------ regards, Bjørn Roald