Re: boost::bind problems with __cdecl and MSVC
Hello Peter,
This can only happen if your default calling convention is something other than __cdecl. This is very rare and boost::bind does not provide explicit support for __cdecl, relying on it being the default.
I am not forcing any specific calling convention: no /Gz (stdcall), /Gr (fastcall), nor /Gd (__cdecl) on my command line. MSDN documents that __cdecl is the default for vararg member functions, but thiscall for non-vararg member functions. The reason for decorating member functions with __cdecl is to get independent of the above mentioned switches when including those header files (thiscall cannot be specified, no keyword). regards, --Daniel
Daniel Boelzle wrote:
Hello Peter,
This can only happen if your default calling convention is something other than __cdecl. This is very rare and boost::bind does not provide explicit support for __cdecl, relying on it being the default.
I am not forcing any specific calling convention: no /Gz (stdcall), /Gr (fastcall), nor /Gd (__cdecl) on my command line. MSDN documents that __cdecl is the default for vararg member functions, but thiscall for non-vararg member functions.
Yes, you're right, I missed this.
The reason for decorating member functions with __cdecl is to get independent of the above mentioned switches when including those header files (thiscall cannot be specified, no keyword).
If you decorate a member function with __cdecl, you are making it __cdecl. If you don't decorate it, it will be __thiscall by default, regardless of /G?. So I don't think you should use __cdecl here unless you really want the "this" pointer pushed on the stack.
Hello Peter,
If you decorate a member function with __cdecl, you are making it __cdecl. If you don't decorate it, it will be __thiscall by default, regardless of /G?. So I don't think you should use __cdecl here unless you really want the "this" pointer pushed on the stack.
I agree, but let me explain the whole story... I want to enable boost::bind for C++-UNO interfaces. UNO (http://udk.openoffice.org/) is the component model of OpenOffice.org and can mediate between different languages, e.g. Python, Java, generating proxies on the fly. The generated header files being used for compilation declare pure virtual __cdecl member functions, thus the this pointer is expected via stack not ecx. Changing the calling convention to thiscall is really no option, because it would break binary compatibility with older C++-UNO components (which can't often be recompiled anyway). regards, --Daniel
Daniel Boelzle wrote:
Hello Peter,
If you decorate a member function with __cdecl, you are making it __cdecl. If you don't decorate it, it will be __thiscall by default, regardless of /G?. So I don't think you should use __cdecl here unless you really want the "this" pointer pushed on the stack.
I agree, but let me explain the whole story... I want to enable boost::bind for C++-UNO interfaces. UNO (http://udk.openoffice.org/) is the component model of OpenOffice.org and can mediate between different languages, e.g. Python, Java, generating proxies on the fly. The generated header files being used for compilation declare pure virtual __cdecl member functions, thus the this pointer is expected via stack not ecx. Changing the calling convention to thiscall is really no option, because it would break binary compatibility with older C++-UNO components (which can't often be recompiled anyway).
Good point. Please do a cvs update. ;-)
participants (2)
-
Daniel Boelzle -
Peter Dimov