Julio M. Merino Vidal wrote:
On 02/04/2007, at 19:11, Andrey Semashev wrote:
Although the discussion is slipping away from the original question, I must say I 100% agree with Jeff. The best solution is to give user a choice whether to link or to go header-only (where possible). And in my opinion such solution should be unified for all boost libs. We already have the BOOST_USE_WINDOWS_H macro, why not extend it to something like BOOST_USE_OS_NATIVE_HEADERS? I think this would settle the problem once and for all. The only problem is I'm not sure how such a transition should be organized.
Although I liked this at first too, it seems to me it cannot be always implemented. I was now trying to add a singleton to my library and I can't do it with headers alone.
oh, oh...
I need to maintain the pointer to the global instance somewhere, and that means having a
because?
global variable which cannot be defined in a header (or otherwise you'll get duplicates). Unless I'm missing something, that is...
Moving it to a library won't solve all the problems either -- you'll be constrained to a dll on windows to guarantee a singleton unless you jump through some big hoops (thread lib had this problem -- still does AFAIK). The problem comes about if 2 dll's link with your static lib...they'll create 2 copies of you singleton at dll init time. Really, I'd rethink the singleton design if at all possible. Jeff