On January 11, 2013 9:15:39 PM "Peter Dimov" <lists@pdimov.com> wrote:
Andrey Semashev wrote:
That would be a useful improvement and there were discussions of this matter recently (in the context of porting Boost.SmatrPtr to Boost.Atomic). In particular, I proposed to provide a header-only interface for types that can be made atomic on the target platform and a separately included spinlock-based fallback that would require linking.
Is there any point in building a static Boost.Atomic library? I see why it'd be necessary to have the spinlock pool in its own DLL on Windows, but a static library doesn't seem to be adding anything. DLLs will still have separate copies of the spinlock pool. You might as well keep it header-only.
If the pool has weak linkage then the header only solution will work. Probably this would be a better solution for single-module applications than linking to a static lib. But care should be taken so that this header-only mode is not enabled accidentally when not intended. Perhaps, wrapping the library into an inline namespace with different names based configuration mode will help in this regard. I did this trick in Boost.Log.