4

In my previous revision game engine I deported major functions for the game editor for C#. Now, I'm beginning to revise the game engine with a static library. There's a already dynamic library created in C++ to use DLLEXPORT for C#. Just now I want to test out the newer functions and created a DLL file from C++. Because the DLL contains classes I was wondering how would I be able to use DLL Export. Would I do this:

[DLLEXPORT("GameEngine.dll", EntryPoint="SomeClass", Conventional=_stdcall)] static extern void functionFromClass();

I have a feeling it's probably DLLImport and not DLLExport. I was wondering how would I go about this? Another way I was thinking was because I already have the DLL in C++ prepared already to go the C# Class Library. I could just keep the new engine as a lib, and link the lib with the old DLL C++ file.

Wouldn't the EntryPoint be able to point to the class the function is in?

Improve this question
0

3 Answers 3

Reset to default
3

You can't actually export C++ classes directly like this.

static extern void functionFromClass();

The problem with C++ is that it doesn't have a universally defined ABI (Application binary interface). So In order to make other languages understand your C++ library ABI you need to wrap it with C functions (almost every other language understands C).

The problem with C is that it doesn't understand classes. On the other hand, C++ Objects need to pass this pointer as a parameter to their member functions. So in order to wrap your C++ classes with C interface. You need to handle passing this parameter explicitly and also define functions similar to the constructor and destructor.

You need to do sth like this:

//Header File Foo.h struct Foo; // Forward Declaration Only Foo* createFoo( /* parameters */ ); void destroyFoo( Foo* obj ); int Func( Foo* obj, int i ); // obj should take this pointer float Func2( Foo* obj, float i, float j );

Implement it like this

#include "Foo.h" extern "C" { Foo* createFoo( const char * s ) { return reinterpret_cast<Foo*>( new Foo( s ) ); } void destroyFoo( Foo* obj ) { delete reinterpret_cast<Foo*>(obj ); } int Func( Foo* obj, int i ) { return reinterpret_cast<Foo*>(obj)->Func(i); } }

Finally you can wrap your exported C function in a C# class so things get back to the traditional object oriented way.

Notice that I didn't even mention Inheritance or polymorphism.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

+1. Time flies by so fast :) As of recently, I've been using CLI for interloping unmanaged code and managed code. I haven't dived into COM development. I may venture into it. :)
2

You cannot import native C++ classes directly to C#. They need to be wrapped one way or another. You can wrap them with C style non-member functions. You'll need to export functions that create and destroy the instances. All in all it's pretty horrid process.

The smart way to do this is to wrap compile the native C++ code into a mixed-mode C++/CLI assembly. You can then expose the functionality as a managed ref class. The interop then becomes trivial and you don't need to run the gauntlet of writing p/invoke declarations by hand.

Improve this answer

4 Comments

So in other words, when creating a managed C++ DLL file, it would be simpler to just use wrap the native code inside the managed CLI C++ then off to C#? Which would make hell lot more easier and in addition, won't be a hassle by consistantly pivoking all the time.
As soon as you start wanting to wrap C++ classes, then you cannot do it with pure C# side p/invoke. You need to write some C++ code. And as soon as you need to do that, C++/CLI is invariably the simplest solution. If you want to wrap for consumption by other than .net then COM would be a candidate, but if not then C++/CLI wins.
I like your answer the most because the very previous engine started as wrapping the core game engine with mixed Native and CLI code. I know it's going to be a very long H file for the DLL but I'm just going to stick with it for now then pick and choose what functions work best to implement for the game side. I'm not sure why C++ get's fussy when I create individual Header files but I'll figure that out as I go along. But thanks everyone for chipping in and helping out!
With this current project I'm doing, CLI is the best approach. I'll have to look into COM Interloping eventually just for learning purposes. :)
2

I Would suggest taking a look at COM Objects and using COM Interop to communicate between Cpp and C# program.

Improve this answer

1 Comment

+1. Thanks. I'll have to dive into COM development eventually. It's something I may find fascinating to learn. As of now, I've been using CLI to interlope native C++ with managed code. :)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.