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)
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk