From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-05-09 01:33:08
David Abrahams vrote:
> Bjørn Roald <bjorn_at_[hidden]> 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
>> is a problem that is specific to DLLs on windows -- where the meaning of
>> writeable static variables is broken. This is AFAIK not an issue with
>> 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
> 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
---- regards Bjørn Roald
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk