Jump to content
  • Advertisement
Sign in to follow this  
squicklid

Exporting a class to DLL for gnu from msvc

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

How would the def file look for exporting a class, or if not using a def file, where would you put declspec(dllexport) and/or extern "C". I searched google for answers but to no avail.

Share this post


Link to post
Share on other sites
Advertisement
If you want to export a class from a DLL using VC++ then you would write the __declspec(dllexport) like so:


class __declspec(dllexport) CTest
{
//blah
};


I've never seen the extern "C" construct used with exporting classes so I'm not sure if it even has any effect. The primary method I've seen it used is with exporting functions from a C++ DLL. Specifying the extern "C" tells the compiler to use C style linkage for those functions so you can call them from the client application by using their original name. You only need this for C++ dlls because of the name mangling which occurs.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
C++ classes are incompatible between compilers. It can't be done.

...Unless you're willing to do some serious assembly code mucking, but it's likely not worth it.

Share this post


Link to post
Share on other sites
What you can do though is export 2 functions that create and destroy an instance of an interface to your class. This works because the virtual function table provides the pointers to all of the relevant code, there's no need for the class's member functions to be exported from the DLL. It goes a little something like this.....

In a common header shared by both the DLL and executable (or another DLL):

class IMyClass
{
public:

// Important, this ensure the correct destructor
// is called when a derived class is destroyed.
virtual ~IMyClass() =0;

// The interface to your class
virtual void DoSomething() = 0;
};



In your DLL:

class MyClass : public IMyClass
{
public:

// The virtual keywords aren't strictly necessary,
// but I usually put them in to make it clear they're
// implementing functions from the base class

virtual ~MyClass() { ... }
virtual void DoSomething() { ... }
};


// I've used a raw pointer here, using smart pointers
// would be better (but watch out for problems with
// the DLL using a different heap, which it probably
// will if you're using 2 different compilers)
declspec(dllexport) IMyClass* CreateMyClass()
{
return new MyClass();
}

// Objects should be deleted from inside the DLL since the
// calling executable could be using a different heap, hence
// the existence of this function
declspec(dllexport) void DestroyMyClass(IMyClass* obj)
{
delete obj;
}

Share this post


Link to post
Share on other sites
To follow on this particular subject :

How can one be sure the virtual functions in the v-table are ordered the same by different compilers ?

Share this post


Link to post
Share on other sites
Quote:
Original post by cnstrnd
To follow on this particular subject :

How can one be sure the virtual functions in the v-table are ordered the same by different compilers ?
You can't, but in practice, they usually are. Multiple or virtual inheritance isn't as likely to work, however.

As long as you use interfaces with no base classes and only virtual functions, and the member function parameters are interfaces or primitive types, you should be OK. This is basically a cheap version of COM. Pretty much every Windows compiler uses the same vtable layout for this reason - compatibilty with COM interfaces.

On other platforms you only have one compiler to worry about, so it doesn't really matter.

Share this post


Link to post
Share on other sites
In addition, you should not put the destructor in the interface, because this allows the user to call delete, when your function calls new, which leads to mis-matched allocations.

Instead, use reference counting, or a "dispose" method on your interface.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!