<div class="gmail_quote">2011/10/23 Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Oct 23, 2011, at 1:51 PM, Ruben Van Boxem wrote:<br>
<br>
> Op 23 okt. 2011 18:51 schreef "Per Lindén" <<a href="mailto:per.linden@lumai.se">per.linden@lumai.se</a>> het volgende:<br>
> ><br>
> > Not sure this is worth mentioning, but since error C2516 is defined as<br>
> > (<a href="http://msdn.microsoft.com/en-us/library/4d8f5kf3%28v=VS.100%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/4d8f5kf3%28v=VS.100%29.aspx</a>)<br>
> > "The class is derived from a type name defined by a typedef statement.",<br>
> > so for example naively changing the second variant of common_type in the<br>
> > test case you posted to <a href="http://connect.microsoft.com" target="_blank">connect.microsoft.com</a> to<br>
> ><br>
> >  template <class _Tp><br>
> >    struct common_type<_Tp, void, void><br>
> >    {<br>
> >    public:<br>
> >        _Tp && type;<br>
> >    };<br>
> ><br>
> > makes the test case compile under VS2010 for me. (probably breaking any<br>
> > intended functionality completely) In any case I get "error C2371:<br>
> > 'size_t' : redefinition; different basic types" from the test case, so<br>
> > maybe reducing it a bit can improve upon the miniscule chance of it<br>
> > being fixed...? You have my vote anyway.<br>
><br>
> I compiled for 64-bit, it's preprocessed source code, so that's the reason. Anyhow, you're probably right. I'll try to reduce it more when I find the time.<br>
><br>
> Howard, is this (the start of) a viable workaround?<br>
<br>
</div>I don't really see how.  common_type<T>::type must be a type, not an object.  It seems strange that VS2010 is letting you derive from an object but not a type.<br>
<br>
You might try this:<br>
<br>
template <class _Tp, class _Arg, bool = is_void<_Tp>::value || is_void<_Arg>::value><br>
struct __is_assignable_imp<br>
    : public decltype(__is_assignable_test(declval<_Tp>(), declval<_Arg>()))<br>
        {};<br>
<br></blockquote><div><br>This shows me this error, signaling that decltype is buggy as I suspected:<br>> testcase.cpp(90) : error C2062: type '' unexpected<br>> testcase.cpp(90) : see reference to class template instantiation 'std::__is_assignable_imp<_Tp,_Arg,__formal>' being compiled<br>
<br>Which only makes the problem worse... I googled <a href="http://stackoverflow.com/questions/7292828/type-deduction-on-parent-class-from-nested-class">this</a> (although seemingly unrelated), suggesting adding a std::identity to accomodate this bug, and <a href="http://stackoverflow.com/questions/6101728/behavior-of-decltype">this</a>, suggesting an intermediate typedef to work around the bug (although I don't see this being possible in this case...<br>
<br>Ruben<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I.e. remove the common_type wrapper around decltype.  However this will have to be #ifdef'd as clang chokes on it:<br>
<br>
type_traits:1185:13: error: expected class name<br>
            decltype((__is_assignable_test(declval<_Tp>(), declval<_Arg>())))<br>
            ^<br>
1 error generated.<br>
<br>
I actually don't know /why/ clang doesn't like this as [class.derived]/p1 appears to allow it (looks like a clang bug to me).<br>
<font color="#888888"><br>
Howard<br>
<br>
</font></blockquote></div><br>