[boost] Re: [Formal review] Singleton library

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-05-14 06:28:32

>>> The problem is about inability of Windows to "merge"
>>> static data from different DLLs into one place.
>>>
>>
> What if I were to move the implementation details that require being 
> only defined once to source files, and by default have those source 
> files included by the headers.  Then if some macro is specified, I could 
> omit these inclusions and instead link to a separate dll that is a build 
> of these files.  Would this solve the problem?

Hi Jason and everybody.

There is a scenario which I think is not solved by this approach, but on 
the other hand may be not solvable a all (I'm pessimistic today...)
Consider a singleton inside a *static* Windows library, which is linked 
into a dynamic library, *and* into an executable, which also links with 
the DLL. Something like this:

    lib (contains a singleton)
     | \
     |  \
     |  dll
     |  /
     | /
    exe

Now the singleton appears twice, once in the DLL's memory, and once in 
the exe's memory.

This is something I found when writing my own singleton library (like 
most of us ;-) ). At first I noticed that singletons in a DLL are 
created twice, so I created a .cpp file and used dllexport/dllimport 
(just like the solution mentioned in this thread) to insure one 
instantiation. This worked for the simple DLL case, but not the more 
complex case I described above. I haven't been able to find any 
workaround (except for being really careful not to create such 
situations), and I really hope you can...

Actually, I didn't have any time to look at your library (very 
unfortunate), but it looks like it will probably suffer from the same 
problem as my own library. I hope I'm wrong... but it worth a check.

Hopefully Boost will soon have a singleton library,
Yuval