On Fri, 5 Mar 2010, Jamie Allsop wrote:
Helge Bahmann wrote:
Hi Jamie,
On Wed, 3 Mar 2010, Jamie Allsop wrote:
With gcc 4.1.2 (gcc 4.3.x is fine) I am seeing this linker error:
.build/debug/working/SourceOne.o: In function `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)': /thirdparty/boost/boost_1_42/boost/smart_ptr/detail/shared_count.hpp:229: multiple definition of `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)' .build/debug/working/SourceTwo.o: /thirdparty/boost/boost_1_42/boost/atomic/detail/gcc-x86.hpp:63: first defined here
[...]
Is this a compiler error or should the specialisation be declared as:
template<> inline void platform_atomic_thread_fence(memory_order order)
you are right, it should have been specialized this way. I have however reorganized my development tree such that this is now handled differently (macros instead of via template specialization), so if you are patient until saturday, this will be resolved.
I patched my copy locally so no rush for me. However I'm curious as to why you'd use a macro when a template would do? Or is it that your changes preclude using templates or other language facilities? I guess I can have a look on Saturday ;)
there has been a request for the abilitiy to detect at compile-time the lock-freedom of atomic data types, in order to being able to pick different data structures and code paths. If I have to define macros for this purpose anyway, there is no good reason anymore to "abuse" templates as much as I do currently. Best regards Helge