On Mon, May 20, 2013 at 1:02 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com" target="_blank">hhinnant@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On May 20, 2013, at 3:29 PM, Rich E <<a href="mailto:reakinator@gmail.com">reakinator@gmail.com</a>> wrote:<br>
<br>
> Hello all,<br>
><br>
> I am trying to help along the recently added Boost.Lockfree (1) library utilize libc++'s std::atomic, as it is currently using Boost.Atomic, and an emulated, locking implementation at that.  <atomic> is currently used for this library for modern gcc and msvc compilers, but not yet clang / libc++.<br>

><br>
><br>
> (note: to enable <atomic> for boost::lockfree, first apply this patch: <a href="https://svn.boost.org/trac/boost/attachment/ticket/8593/lockfree_atomic_libcpp.patch" target="_blank">https://svn.boost.org/trac/boost/attachment/ticket/8593/lockfree_atomic_libcpp.patch</a> )<br>

><br>
> The problem can be seen in the compile errors for this simple program:<br>
><br>
> #include "boost/lockfree/queue.hpp"<br>
><br>
> int main(int argc, const char * argv[])<br>
> {<br>
>   boost::lockfree::queue<int> q( 1 );<br>
>   return 0;<br>
> }<br>
><br>
> The diagnostic is:<br>
><br>
> In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/memory:606:<br>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/atomic:623:58: error: no viable conversion from 'boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>' to '_Atomic(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>)'<br>

>     _LIBCPP_CONSTEXPR __atomic_base(_Tp __d) _NOEXCEPT : __a_(__d) {}<br>
>                                                          ^    ~~~<br>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/atomic:727:51: note: in instantiation of member function 'std::__1::__atomic_base<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, false>::__atomic_base' requested here<br>

>     _LIBCPP_CONSTEXPR atomic(_Tp __d) _NOEXCEPT : __base(__d) {}<br>
>                                                   ^<br>
> ../../../../../cinder-dev/boost/boost/lockfree/queue.hpp:192:9: note: in instantiation of member function 'std::__1::atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> >::atomic' requested here<br>

>         head_(tagged_node_handle(0, 0)),<br>
>         ^<br>
> /Users/richeakin/code/cinder/audio-rewrite/audio2/test/BasicTest/xcode/../src/BasicTestApp.cpp:75:30: note: in instantiation of member function 'boost::lockfree::queue<int, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::queue' requested here<br>

>         boost::lockfree::queue<int> q( 1 );<br>
>                                     ^<br>
> ../../../../../cinder-dev/boost/boost/lockfree/detail/tagged_ptr_dcas.hpp:112:5: note: candidate function<br>
>     operator bool(void) const<br>
>     ^<br>
><br>
><br>
> My understanding is (please correct me if wrong) that _Atomic(_Tp) is a directive to the compiler, which is replaced with atomic the true atomic instructions for each given architecture. As such, it doesn't know how to replace boost::lockfree::detail::tagged_ptr<...> with size_t, or whatever other atomic value lockfree expects. But, this is where my understanding of this sort of template metaprogramming reaches its end, I just can't tell why this trips up with libc++ but not with vc11.<br>

><br>
> Can anyone see where the translation falls short, or have suggestions on how to proceeed?<br>
<br>
</div></div>This looks like a clang bug to me.  _Atomic seems to not be set up to deal with non-integral types.<br></blockquote><div><br></div><div>I don't think this is clearly a clang bug. We support _Atomic(T) in C++ mode as an extension, but that extension currently does not extend to allowing an _Atomic(T) to be initialized as if it were a T, if T is of class type. We can only reasonably support this when T's corresponding constructor is trivial, but I believe that's all you actually need here, right? (We don't want to allow calling member functions on an object of type T which is wrapped within an _Atomic(...)).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a simplified version of Rich's test:<br>
<br>
#include <atomic><br>
<br>
struct A<br>
{<br>
    A(int) {}<br>
};<br>
<br>
int<br>
main()<br>
{<br>
    std::atomic<A> q(A(1));<br>
}<br>
<br>
Howard<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br>