Sign in to follow this  

return values and calling convention

This topic is 4275 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

Hi, I have an object implemented in a dll, wich is used by the executable. lets call it iobjectmanager. I have this method in the objectmanager: [code\] virtual _stdcall smartptr<object> getObject(const char* name)=0 [\code] And I get errors calling this function when the exe is compiled by VC2005 express, and the dll is compiled by mingw. Do you know if it may be caused by the function returning a complex type.

Share this post


Link to post
Share on other sites
Different compilers mangle names differently. That means unless you use a non-C++ linkage for your functions, there's a good chance you can't link objects compiled by one compiler and object compiled by another compiler (or even different versions of the same compiler).

One suggestion is to give your function "C" linkage (use extern "C").

You may also run into iter problems, though, such as member alignment in structures.

Share this post


Link to post
Share on other sites
A little off-topic, but passing pointers across a DLL boundary is A Bad Thing. If your smartptr class deletes the object from within the module it's allocated, then all is well.

Also, since this is a virtual function, I presume you're exporting an entire class. Exporting classes is a very compiler-specific thing, so you're likely going to have to compile the exe and dll with the same compiler.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What kind of error? At run-time or at compile-time?

Share this post


Link to post
Share on other sites
Thank you for your answers. I will explain in detail how my system work. I use abstract (pure virtual) classes. the object class is something like this:

class iObject
{
public:
virtual _stdcall void incRef()=0;
virtual _stdcall void decRef()=0;
}

my objectmanager is also an abstract class, derived from iObject. My program get a pointer to the objectmanager by calling an extern"C" initialisation function. And my "smart pointer" class is just a pointer, calling incRef and decRef at proper times. The decRef functions, implemented in the dll, free the object. I don't really "export" the class.

The implementation of objectmanager is in the dll, compiled with mingw, and the exe is compiled with visual C++.

The problem arise when a call the getGlobalObject() function of my objectmanager from the exe. I get an access violation somewhere near the end of getGlobalObject's code in the dll. If I return a raw pointer, I don't get the problem. So I guess it comes from how mingw deals with returning objects.

I'm using this system to enable the creation of plugins for my engine, and I would like to be able to create plugins with any c++ compilers.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrakeSlayer
I'm using this system to enable the creation of plugins for my engine, and I would like to be able to create plugins with any c++ compilers.


This has not much to do with how a value is returned by a function.

The C++ standard don't tell the compiler how it should generate the code - this is an implementation defined behaviour. It means that you can't be sure that the code generated by VC will hav the same layout than the code generated by mingw - this is true for the code, and this is also true for the data layout. The more complex the object is, the more difference you'll have. As a consequence, you can't mix C++ code that has been compiled with VC and C++ code that has been compiled with mingw.

You have no way to bypass this - unless you use only POD types with known packing and alignement.

Regards,

Share this post


Link to post
Share on other sites

This topic is 4275 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this