boost::bind, problem with result type deduction and calling conventions

hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ? template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; }; so that code like class A { public: int __stdcall x() { return 0; } void const y() {} explicit A() { typedef boost::function<int()> fun_t; fun_t const f(boost::bind(&A::x,this)); } }; ends up with an warning at bind 1>G:\boost\boost_1_37_0\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored 1> G:\boost\boost_1_37_0\boost/bind.hpp(1682) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> I=1 1> ] 1> G:\dev\workspace\files\ado\ado_bind.hxx(36) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> A1=Ado::A * 1> ] because the proposed specialization is not choosen by the compiler. Adding an __stdcall to the function signature type in add_cref fixes that problem, but still i do no understand, why the defintion is not like template< class M, class T > struct add_cref< M (__stdcall T::*) (), 1 > { typedef M const& type; }; and of course that fix is only applicable for __stdcall, where specialzations for other calling conventions can easily be generated, like for mem_fn_cc in respect to requested support for calling conventions. Thanks for your help, ILo. compiler : msvc 8.0 library : boost 1.38

Ingo.Loehken:
hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ?
template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; };
This specialization's only purpose is to avoid the warning; whether the type is void or something else doesn't matter. Ironically, it doesn't work on recent versions on MSVC due to a compiler bug.
participants (2)
-
Ingo.Loehken@boc-eu.com
-
Peter Dimov