Printable View
I'm aware that Microsoft's 64-bit compilers now have only one calling convention. So __cdecl, __stdcall, __fastcall and (apparently) even __thiscall are now all equivalent.
So what happens if I'm building some older code which explicitly declared a calling convention. If the compiler encounters a symbol that's explicitly declared as __cdecl, __stdcall or whatever is that regarded as an error or does it just get ignored?
64bit code on MS only has "__fastcall"
older compiled code is irrelevant, as it won't be 64bit code. the MS compilers never supported anything else.
if you talk about using object code that was created with another compiler and you want to link it with MSVC code... Well that'll only work if that other compiler also used the MS methodology (which is also used for the Windows API calls btw).
if that other compiler doesn't do it the MS __fastcall way... "anything could happen".
if you're merely talking about compiling old C/C++ sources...
the other conventions are ignored at compile time. this is mentioned in the help for those calling conventions. for __cdecl for instance:
"On Itanium Processor Family (IPF) and x64 processors, __cdecl is accepted and ignoredby the compiler; on IPF, by convention, parameters are passed in register. "
Yes, I was talking about compiling older sources. I just wanted to make sure that if I encountered a header file like this (which I find to be reasonably common) the lines #define THE_DLL_CALLTYPE __stdcall aren't going to spoil a 64-bit build:-
Also do you happen to know what the situation is for the gcc compiler? i.e. does it also use one common type for 64-bit builds or does it continue to differentiate between cdecl / fastcall etc? If my code needs to be cross-platform I guess I should find this out.! :)Code:#ifdef BUILDING_SOME_DLL
#define THE_DLL_API __declspec(dllexport)
#define THE_DLL_CALLTYPE __stdcall
#else
#define THE_DLL_API __declspec(dllimport)
#define THE_DLL_CALLTYPE __stdcall
#endif
THE_DLL_API void THE_DLL_CALLTYPE somefunc(void);
Thanks Igor. What's interesting (if I'm reading the table correctly) is that Microsoft's x64 calling convention isn't (quite) __fastcall because __fastcall asks the callee to clean up the stack whereas the caller does the cleanup for MS x64. Interesting.... :cool:
See MSDN for the details behind the design: Overview of x64 Calling Conventions
calling conventions in dlls "don"t matter". That is to say, they matter only in that the caller needs to use the same method as what the dll was designed for, but other than that, you could use any method (even custom ones) in so far as caller and callee agree.
__stdcall for dll's is popular because that's the system that is most commonly used in other languages. So if you wanted to use a dll from basic, pascal, ... then __stdcall makes that possible. the other calling conventions will either not work or will need a thunk written in assembly. So __stdcall (formerly called __pascal) is the go-to for libs and dll's which you want to be accessible from more than just C/C++.
With x64, MS decided that having multiple conventions only makes things harder, so they opted for a single convention that tries to combine the best of everything.
So they took __fastcall as a base (pass by register for performance/size)
make it allow for variable arguments (the perk of __cdecl) by having the caller clean up the stack
in addition they decided that some registers would be considered preserved and others volatile.
And by making this the convention for the Win api. Any language that wants to work on windows would have to support the method anyway. So multiple conventions to support other languages isn't a requirement.
The __stdcall perk which is smaller code by not requiring each caller to clean up the stack but make the callee be responsible isn't usefull because that means you can't have variable arguments.