COM wrapper, __cdecl and __stdcall
-
I am currently designing custom wrappers of ADO objects for a series of related MFC projects. Each wrapper is just a generic C++ class with simple functions that hide much of the ADO property/method complexity. ADO objects are interfaced through #import directive. While carefully studying the structure of *.tlh file, I noticed that all the member functions of smart pointer wrappers are __stdcall type (like Win32 API), whereas the default setting in my MFC project is __cdecl. Then I understand that smart pointer functions will be __stdcall, whereas all of my wrapper functions will be labeled __cdecl during compilation step. Questions: 1) Do I need to explicitly label each one of them in code with __stdcall as well, or __cdecl callers of __stdcall methods do not interfere with each other? 2) Does anyone know when when exactly is it preferred to overide __cdecl with __stdcall? 3) What are the advantages of one calling convention over another? Thanks. Kirill
-
I am currently designing custom wrappers of ADO objects for a series of related MFC projects. Each wrapper is just a generic C++ class with simple functions that hide much of the ADO property/method complexity. ADO objects are interfaced through #import directive. While carefully studying the structure of *.tlh file, I noticed that all the member functions of smart pointer wrappers are __stdcall type (like Win32 API), whereas the default setting in my MFC project is __cdecl. Then I understand that smart pointer functions will be __stdcall, whereas all of my wrapper functions will be labeled __cdecl during compilation step. Questions: 1) Do I need to explicitly label each one of them in code with __stdcall as well, or __cdecl callers of __stdcall methods do not interfere with each other? 2) Does anyone know when when exactly is it preferred to overide __cdecl with __stdcall? 3) What are the advantages of one calling convention over another? Thanks. Kirill
- There's no interference at all. You can invoke a function having whatever calling convention from any other function with different calling convention as long as the caller knows in advance the proper calling convention of the callee. 2) 3) Nemanja Trifunovic's Calling Conventions Demystified explains it all about CCs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
I am currently designing custom wrappers of ADO objects for a series of related MFC projects. Each wrapper is just a generic C++ class with simple functions that hide much of the ADO property/method complexity. ADO objects are interfaced through #import directive. While carefully studying the structure of *.tlh file, I noticed that all the member functions of smart pointer wrappers are __stdcall type (like Win32 API), whereas the default setting in my MFC project is __cdecl. Then I understand that smart pointer functions will be __stdcall, whereas all of my wrapper functions will be labeled __cdecl during compilation step. Questions: 1) Do I need to explicitly label each one of them in code with __stdcall as well, or __cdecl callers of __stdcall methods do not interfere with each other? 2) Does anyone know when when exactly is it preferred to overide __cdecl with __stdcall? 3) What are the advantages of one calling convention over another? Thanks. Kirill
-
I am currently designing custom wrappers of ADO objects for a series of related MFC projects. Each wrapper is just a generic C++ class with simple functions that hide much of the ADO property/method complexity. ADO objects are interfaced through #import directive. While carefully studying the structure of *.tlh file, I noticed that all the member functions of smart pointer wrappers are __stdcall type (like Win32 API), whereas the default setting in my MFC project is __cdecl. Then I understand that smart pointer functions will be __stdcall, whereas all of my wrapper functions will be labeled __cdecl during compilation step. Questions: 1) Do I need to explicitly label each one of them in code with __stdcall as well, or __cdecl callers of __stdcall methods do not interfere with each other? 2) Does anyone know when when exactly is it preferred to overide __cdecl with __stdcall? 3) What are the advantages of one calling convention over another? Thanks. Kirill
Most COM functions are __stdcall. You will probably create some confusion if using __cdecl. Also note that you will only be able to connect to C/C++ clients using __cdecl, which somewhat defies the purpose of COM. I suggest you only use __cdecl if you need variable parameters, and really can't think of a way around this. /moliate
-
Most COM functions are __stdcall. You will probably create some confusion if using __cdecl. Also note that you will only be able to connect to C/C++ clients using __cdecl, which somewhat defies the purpose of COM. I suggest you only use __cdecl if you need variable parameters, and really can't think of a way around this. /moliate
This is off of the topic from the original question, but it may shed some light on why particular conventions were chosen. The key to all COM object interfaces is that they all have to use __stdcall. That is how it becomes safe to call objects that some complete stranger wrote with this model. Everyone uses the same calling convention. The reason why this convention was chosen over _cdecl, is that the variable length parameter lists make this format unsafe if an interface function call needs to be marshalled to another machine, the proxy code would not know how many parameters and what types they are to marshal.