David Abrahams vrote:
Bjørn Roald <bjorn@4roald.org> writes:
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.
If you are referring to the fact that static variables with the same name can be allocated in multiple DLLs, so that you see different values from each DLL, your information is incorrect and I disagree with your characterization of it as "broken". GCC now supports restricting symbol visibility for ELF platforms. See
http://www.nedprod.com/programs/gccvisibility.html
As I see it, this model (essentially the Windows model) is actually much less broken than the usual one on Unix where everything forms a big "symbol soup."
You left out the portion of my post where I mentioned that Windows DLLs have benefits, I certainly agree that their ability to provide much better encapsulation than other models is great. That is not what I think is broken. Your information about GCC was new to me and interresting, I will study it in detail when I get more time. Thanks :) The problem I refer to, which I think is the relevant problem for this thread is that static variables are instanciated by the DLL loader or whatever, in a manner where there becomes more than one instance of the same static variable in the same process. This is not consistent with my understanding of the C++ language. If these static variables are constants or initialized consistently and treated as constants, this never becomes a real problem. I however they are writable and are writen to you end up with with more than one value for the same static variable in the same program. In my view this is broken. It has been some years since I did heavy work with Windows, the tools I used was MSVC++ 5.0 + Dincumware's sepearate standard library (not the one bunndled by MS in those days). Dinkumware provided standard libraries that fixed these issues and others providing DLL compliance, something MS never informed their customers that the bundeled versions where not designed to do. If I remember right, the static writable issue was the hardest nut to crack even for Dinkumware gurus. I think this should be fixed since it makes programming more dificult than needed. I know there may be a defendable position taken to argue that this is not broken, since the C++ standard does not say much about what a program is. In addition MS defines something they call context (if I remember right). You can explicitly switch between the context of one DLL to the context of another, thus controlling which static variable instance you are working on. So a DLL based program probably only have only one instance of a static variable per context. This may AFAIK be suficient to claim C++ compliancy. But I considder this to be something almost none of the C++ developers I have ever met is aware of. So if it holds water, I am not realy interested -- I still cosidder it broken. For the singelton library, it may be possible to always switch context to the DLL owning the singelton before the static variable is accessed. I have not had time to study the libray code yet, so I do not know how hard this may be to get right. If this is done properly, use of shared memory may not be needed. ---- regards Bjørn Roald