Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

serratemplar

what is __stdcall?

This topic is 5274 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!