Re: [boost] Re: Re: Re: [Formal review] Singleton library

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-05-07 16:29:53

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