5 ms·
At least MSVC on x86 uses "thiscall" by default which puts the this pointer in ecx. You cannot call those functions from C without specific compiler support.
by poizan42 10y ago
At least MSVC on x86 uses "thiscall" by default which puts the this pointer in ecx. You cannot call those functions from C without specific compiler support.
- vardump 10y agoSure you can. Just write an asm stub to call, that sets up ecx and other things right.
- poizan42 10y agoThe claim was: The same goes for C++ or Swift. Getting the function pointer for a method can be involved, but all functions adhere to the C ABI. This is clearly false since at least one C++ compiler generates functions that does not adhere to any of the common calling conventions for C on that platform (or "C ABIs" if you will). Besides that, I said you could not call them from C. An asm stub is not C. Neither is inline assembly even though it's a common extension to C.
- jheriko 10y agothats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler... but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).
- poizan42 10y ago> thats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler... Some x86 C compilers supports calling conventions that lets you put things in registers, e.g. Microsofts "fastcall". But I wouldn't consider that part of the standard "C ABI" for Windows given that it's practically never used for externally visible functions. As I said "without specfic compiler support". Using inline assembler is just cheating, it's not C. > but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least). That is more about name mangling schemes and layout of standard library classes though. As far as I know the calling conventions has been quite fixed for a long time.