If you're passing C++ classes around across DLL boundaries without using interfaces then you're doing it wrong, regardless of the managed/unmanaged setup.

Other than that, if you wish to use a "C++ class" or an unmanaged interface from .net you will have to use C++/CLI to wrap it. Unless it's a COM object, in which case .net can generate a wrapper for it.

If we're talking non-member functions and structs, then you can use pinvoke.

[quote name='Washu' timestamp='1328245767' post='4909010']
If you're passing C++ classes around across DLL boundaries without using interfaces then you're doing it wrong, regardless of the managed/unmanaged setup.

There are no interfaces in unmanaged c++, unless by interface you mean an ADT, which is purely situational in unmanaged code.

Could you please explain why? As long as I am implicitly linking to my dll's, they all share the same heap, so what is the issue?

Also, I was originally wanting to implement my game engine(via dll's) in a windows form application(map editor), but then I realized there is c++ windows forms. So if that simplifies the answer at all, great!
[/quote]
By interface I mean a pure abstract class. Which is an interface. I.e. IUnknown.

The reason passing classes around between DLLs and executables without using interface is "bad" is simply this:
Its highly compiler dependent. If your DLLs are always built with the same compiler using the same build settings (release/debug, etc), then it should be all fine and dandy. But that means your DLLs are pretty much useless outside of that scenario. This is because name mangling, object layout, heck even packing differs from compiler to compiler and even from version to version.

The advantage of interfaces is that they are typically all implemented in an identical fashion. While C++ doesn't have an ABI, COM does enforce an ABI on COM interfaces, and almost every C++ compiler on the planet can produce and consume COM interfaces.