what is __stdcall?
Author
We''re working with VC++ by the way.
msdn.com says it''s a "calling convention used to call Win32 API functions" and it''s used thus...
return-type __stdcall function-name(argument-list)
and in my bit of research I learned that it is, if not the opposite, different than the "standard calling convention" __cdecl. I''ve read the definitions for the two but I''m not understanding just what their respective usefulness is.
I''m currently studying an article discussing resource file use and the load, save, and unload functions it uses for examples are all defined thus:
bool __stdcall(* lpLoad)(fstream *, LPRESFILELUMP);
Potentially, lpload is a function ptr to a load function that will load a given data lump...so the resource file manager can be updated to work with varying kinds of files.
So, what is this __stdcall identifier all about? Any info at all is appreciated; thanks in advance.
Author
So, the way I understand it now is, unless I''m going to be integrating inline assembler into my programs, I''ll never need to specify a function as __stdcall, __cdecl, or __fastcall.
I downloaded an assembler tutorial, but I''m leaving that for later in the summer: I have a CS course in assembler and architecure in the fall so I want my own review to be fresh in my mind when I go.
Thanks again.
I downloaded an assembler tutorial, but I''m leaving that for later in the summer: I have a CS course in assembler and architecure in the fall so I want my own review to be fresh in my mind when I go.
Thanks again.
Or if you''re working with DLLs where the default calling convention was altered. Or you''re working on a project where the default calling convention is stdcall or fastcall and you need to create a vararg function. Or you''re using function pointers to access windows API functions via GetProcAddress(). Or you need to interface properly with MSVC''s atexit() functions.
Fortunately most of the non-DLL situations will simply fail to compile if you don''t use the properly calling convention specification, and most of the the the DLL situations will give you a runtime error that specifically says that there was probably a calling convention mix-up.
Fortunately most of the non-DLL situations will simply fail to compile if you don''t use the properly calling convention specification, and most of the the the DLL situations will give you a runtime error that specifically says that there was probably a calling convention mix-up.
As well as the DLL issues, there are other fairly places where putting the calling convention is important.
One example is when you''re using function pointers - you need to ensure the function pointed to uses the same convention as the function calling through the pointer.
Somewhere this often happens is when you''re using C runtime library functions that require user provided callbacks. If your callback is written in C++ - e.g. the "compare" function passed to the "qsort()" function *must* be declared as __cdecl - which it won''t be if your function is in a C++ file.
Simon O''Connor
Game Programmer &
Microsoft DirectX MVP
One example is when you''re using function pointers - you need to ensure the function pointed to uses the same convention as the function calling through the pointer.
Somewhere this often happens is when you''re using C runtime library functions that require user provided callbacks. If your callback is written in C++ - e.g. the "compare" function passed to the "qsort()" function *must* be declared as __cdecl - which it won''t be if your function is in a C++ file.
Simon O''Connor
Game Programmer &
Microsoft DirectX MVP
please note that that link above is only correct for Microsoft compilers.
If you are using Borland or Intel compilers, they have them defined as so:
__msfastcall(ECX,EBX) (ie the same as the Microsoft compiler)
__fastcall(EAX,EBX,ECX)
and even when not using assembly, aslong as your data is 32bits or smaller, it will make your function faster.
If you are using Borland or Intel compilers, they have them defined as so:
__msfastcall(ECX,EBX) (ie the same as the Microsoft compiler)
__fastcall(EAX,EBX,ECX)
and even when not using assembly, aslong as your data is 32bits or smaller, it will make your function faster.
There''s also __thiscall, which passes the "this" parameter in ecx.
Anyway, you shouldn''t need to worry about it. Default functions get default calling conventions and linkage, and Windows API functions, that use __stdcall conventions, are already tagged like that in the Windows headers. Only if you do advanced shared library export stuff do you need to worry about this.
Anyway, you shouldn''t need to worry about it. Default functions get default calling conventions and linkage, and Windows API functions, that use __stdcall conventions, are already tagged like that in the Windows headers. Only if you do advanced shared library export stuff do you need to worry about this.
Author
Okay... =)
So, the function prototype I previously listed:
bool __stdcall(* lpLoad)(fstream *, LPRESFILELUMP);
which is basically a template, is saying the function that lpLoad points to is to use the "standard calling convention."
I''m going to hazard a shot in the dark and guess that basically all functions in a Visual C++ built app use __stdcall...so I declare dynamically-linked functions with it to make sure?
Thanks again for all the info.
So, the function prototype I previously listed:
bool __stdcall(* lpLoad)(fstream *, LPRESFILELUMP);
which is basically a template, is saying the function that lpLoad points to is to use the "standard calling convention."
I''m going to hazard a shot in the dark and guess that basically all functions in a Visual C++ built app use __stdcall...so I declare dynamically-linked functions with it to make sure?
Thanks again for all the info.
Visual C++ has a project setting to determine the default calling convention of functions. (/Gd, /Gr or /Gz if you want to look up the flags.) The default default calling convention is __cdecl.
Author
Okay. =) So, since I'm not working with assembler, or .dll's, GetProcAddress(), or atexit(), I really don't need to worry about it yet. =) I know so little about assembler anyway; like I said, next fall.
I would like to use .dll's though for my next project, and resource files (which was the entire origin of this post). Look forward to my questions on dlls. =)
Thanks again everyone.
While we're on the topic, what is a "vararg" function?
EDIT: a rather unsightly typo that I couldn't let go.
[edited by - serratemplar on June 5, 2004 11:25:15 PM]
I would like to use .dll's though for my next project, and resource files (which was the entire origin of this post). Look forward to my questions on dlls. =)
Thanks again everyone.
While we're on the topic, what is a "vararg" function?
EDIT: a rather unsightly typo that I couldn't let go.
[edited by - serratemplar on June 5, 2004 11:25:15 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
