DLL exported functions - calling conventions and return types

I've been trying to figure out if it matters which calling convention we use for DLL's exported functions. It seems that since both caller (one that loads the DLL and calls the function) and callee (DLL functions) reside in the same address space (i.e. same process), whether we use _stdcall or _cdecl as calling convention for the exported functions shouldn't matter. Is this correct?

Also, is there a restriction on the return type of the exported functions? I think primitive return types might be all allowed, but I wasn't sure about struct or class as a return type.

If I have something like

Code:

---

class CMyClass {
...
};

CMyClass _stdcall func()
{
...
}

---

Is this allowed?

Now, say that I have a function member (pointer) that points to some heap memory. Can I have the exported function returrn a pointer to this address, and both use and free the memory from the caller's code?

Quote:

---

It seems that since both caller (one that loads the DLL and calls the function) and callee (DLL functions) reside in the same address space (i.e. same process), whether we use _stdcall or _cdecl shouldn't matter. Is this correct?

---

Correct.

Quote:

---

Also, is there a restriction on the return type of the exported functions? I think primitive return types might be all allowed, but I wasn't sure about struct or class as a return type.

---

For everything to work properly, classes returned from/passed to the DLL must be 100% binary compatible. This basically boils down to "compiled on the same machine using the same codebase". For this reason, the practice is generally discouraged. Consider instead a pure C API but ship a header file that wraps everything into a C++ class.

Quote:

---

Now, say that I have a function member (pointer) that points to some heap memory. Can I have the exported function returrn a pointer to this address, and both use and free the memory from the caller's code?

---

Yes.

Ok, I see. Great, thanks!