[C++] DLL - extern "C" and class objects

I want to create a dll in C++ (NOT MFC) in a way so that others can use the functionality that i've build in my dll. So with other words, when someone is programming C#, he should be able to add my DLL as reference and have access to the functions of that dll.

Now i've read a topic about that here on how to do that:
http://www.codeguru.com/forum/showthread.php?t=231254

So all i have to do according to that post is declare my functions as extern "C" and create a DEF file. But i have a question about using extern "C".


I have a main.cpp file in my dll which has the folliwing main code:

Code:

---

BOOL WINAPI DllMain(HINSTANCE hInstance,DWORD fwdReason, LPVOID lpvReserved)
{
        switch(fwdReason)
        {
                case DLL_PROCESS_ATTACH:
                        break;
                case DLL_THREAD_ATTACH:
                        break;
                case DLL_PROCESS_DETACH:
                        break;
                case DLL_THREAD_DETACH:
                        break;
        }
        return(TRUE);        // The initialization was successful, a FALSE will abort
                        // the DLL attach
}

---

I also have to other files, test.h and test.cpp. The headerfile contains the structure of my class:

Code:

---

class cTest
{
public:
void MyFunc ( );
}

---

and the sourcefile has the logic of my class:

Code:

---

void cTest::MyFunc ( )
{
    MessageBox ( NULL, "The test worked!", "Test", MB_OK );
}

---

So my question now is, how do i use extern "C" in my case?? What i want is when others use my DLL is that they have access to my classes. So that they can simply say something like this in their application:

cTest test = new cTest();
test.MyFunc();

Do i just encapsulate my entire class in a extern "C" block?? like so:

Code:

---

extern "C"
{
  //my entire class
  //comes in here
}

---

Or can i only use structs in this case??

Well, i really hope someone here can help me out with my questions :(

Thanks for any help!

The "extern "C"" block specifies that functions declared within it should be compiled so as to appear as C functions to the outside world. They can have C++-only constructs within them; but the function interfaces must follow C rules.

That means, no classes, no struct methods, no function overloading, no operators, etc.

In general, a DLL boundary should be even *more* strict: Not only should you not try to send C++ objects across the boundary, but you should avoid sending anything except primitives across the boundary. The DLL could have been built with different compile settings than the program it's being used in, and, for instance, a struct may not have precisely the same layout in memory within the DLL as it does outside as a result.

Bottom line: If the cTest class and methods are defined within the DLL, then you can use cTest objects in the client program, and you can use cTest objects in the DLL, but you cannot operate as if they are the same type of objects in both places.

What you could do is have the DLL hand out a pointer to a cTest, and later accept that same pointer back into another DLL method as an argument. Pointers can cross the DLL boundary fine. But if the cTest the pointer is directed at was created within the DLL, it is invalid to dereference the pointer outside of the DLL; and vice versa. Pointers which cross the boundary must be treated as opaque handles.

Classes exported from C++ Dll cannot be used directly by C# client. To solve this interoperability problem, you have the following options:
1. Using extern C exported functions, make C-style wrapper for the class. This wrapper should have functions Create, Release and wrapper function for every public class method which should have class pointer parameter returned by Create. C# client can work with this Dll using PInvoke.
2. Write COM class - it can be used by C# client by the way you want: Add Reference.
3. Make C++/CLI wrapper for your class, or write this class directly in C++/CLI. Such library may be used by C# by adding reference and creating clas instances, as any other .NET class library.

Thanks both, for the answers. I never thought it would be this complicated to create a dl.

I guess i'll have to release 2 different DLL's. One for C++ programmers and one for C# .NET programmers.

But for now i'll just start with a DLL that works for C++ programmers only. Now what do i have to do so they can use my DLL in Visual Studio?
Ofcourse i still have classes in that dll. Do i still need to do 'special' things in my code? Like extenr "C"?

Quote:

---

Originally Posted by vivendi

But for now i'll just start with a DLL that works for C++ programmers only. Now what do i have to do so they can use my DLL in Visual Studio?
Ofcourse i still have classes in that dll. Do i still need to do 'special' things in my code? Like extenr "C"?

---

It's not compulsory for that specific purpose but you'd still be well advised to use it. One of the effects of extern "C" is to turn off symbol decoration (name mangling). Mangled names are different for different compilers. If you don't turn it off, anyone who wants to use your DLL will have to be using the same compiler version that you use. e.g. if you're using VC++8, the resulting DLL wouldn't be useable by somebody working with a different compiler, such as VC++6 etc.

Quote:

---

I never thought it would be this complicated to create a dl.

---

This is you who makes this so complicated. :) You've got the answer: you have to create a module compatible across the languages in your list. COM object is the most generic solution. Managed wrapper will work for "C++ and .NET language" case only. And direct use of native C++ classes never was possible for languages other than C++. So, there's nothing complex to create a dll. To create a dll compatible with different languages is more complex for sure. Just get rid of C++ classes, and the issue becomes really simple.

Now write C++/CLI wrapper for your C++ library. Create C++/CLI Class Library, link it to unmanaged Dll and wrap all unmanaged class methods.
This library can be used by C# client like any other .NET library.