Refering to Class, Types, and Functions from Dlls

[safaci2000]

Hi all,

I have a DLL that I need to access. I've managed to load it and
unload it successfully. The compiler is happy no complaints or
warning.

I need to refer to a class object that was defined in the class, and
I'm not sure how to go about it.

I understand that if I need to call a function I'd need to call
GetProcAddress(hDll,"funcFoo"); that would return a pointer to the
function and then I'd use the pointer to address the function inside
of my program.

what would I need to do to refer to the Dll, types.

If I was in a regular C++ program, I would be doing something like

ClassFoo.Host myhost; // assuming Host if an internal class, is
public and is well defined.

How would I be able to do that if my class Foo is defined inside the
dll?

 

[Guest]

If it's a native app (not managed) then you simply include the header file of
the type you want to reference.

 

[Ben Voigt]

If it's a native app (not managed) then you simply include the header file
of
the type you want to reference.

Trying to dllimport native C++ classes is a bad idea which will cause you no
end of trouble down the road. I suggest you rearchitect your application
with a C-compatible interface (with proper memory manager separation), which
is a proven and reliable means of developing DLLs. The object-oriented
version would be COM, and I suggest that if someone gave you a closed source
DLL that "contains a class", it is most likely a COM coclass. To confirm
that, use the oleview SDK tool to check for the presence of a type library.
To use it you load the DLL, GetProcAddress its DllRegisterServer function
and call it, making Windows aware of the coclass, and then use
CoCreateInstance to create an instance of the class, probably using the
com_ptr compiler support.

 

[Peter Nimmo]

Trying to dllimport native C++ classes is a bad idea which will cause
you no end of trouble down the road.

What problems are those? The only problems I have found have occured when
I have had a mismatch between run-time library settings between providers
and consumers of classes (i.e trying to free memory allocated by a
different runtime library). Other than that it has been plain sailing.

Obviously the components you write should be all written using the same
version of the compiler, and so if that is not possible then its a bad
idea.


Peter

 

[Ben Voigt [C++ MVP]]

What problems are those? The only problems I have found have occured when
I have had a mismatch between run-time library settings between providers
and consumers of classes (i.e trying to free memory allocated by a
different runtime library). Other than that it has been plain sailing.

Obviously the components you write should be all written using the same
version of the compiler, and so if that is not possible then its a bad
idea.

If you require all the components to be compiled with the same compiler,
same macros, same settings, what do you gain by having a DLL?

 

[Peter Nimmo]

If you require all the components to be compiled with the same
compiler, same macros, same settings, what do you gain by having a
DLL?

Drop in replacement without the need to relink the object files/libraries.
If you have designed your interfaces properly then you can change the
implementation of a class, recompile your dll and swap the old one for the
new and bobs your mothers brother.

The components do not need to use the same macros and compiler settings
other than run-time library.

 

[Guest]

How can you DllImport a native C++ class in managed code?

 

[Ben Voigt [C++ MVP]]

Drop in replacement without the need to relink the object files/libraries.
If you have designed your interfaces properly then you can change the
implementation of a class, recompile your dll and swap the old one for the
new and bobs your mothers brother.

The components do not need to use the same macros and compiler settings
other than run-time library.

In that case, you needn't share C++ types with dllimport at all.
__declspec(dllimport) is only used when you are sharing not only interfaces,
but implementation detail, and then you will need to have compiler settings
and macros matching, nor even compiler version.

Unless by interfaces, you mean something other than classes consisting of
pure virtual methods only. In that case, you are in trouble, because the
compiler is placing layout offsets directly into the code on both sides, and
they will not match in case macros or compiler settings aren't the same.

 

[Ben Voigt [C++ MVP]]

How can you DllImport a native C++ class in managed code?

You can't.

I was speaking about __declspec(dllimport), not
System::Runtime::InteropServices:llImportAttribute

 

[Guest]

Ah, okay. You're comment "Trying to dllimport native C++ classes is a bad
idea..." got me thinking you were talking specifically about importing a
class not functions/methods. A physical impossibility as far as I knew...

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

 

[Ben Voigt [C++ MVP]]

Ah, okay. You're comment "Trying to dllimport native C++ classes is a bad
idea..." got me thinking you were talking specifically about importing a
class not functions/methods. A physical impossibility as far as I knew...

I was talking about the whole class. Using __declspec(dllimport), from C++
(native) into C++ (native or managed). It is impossible with P/Invoke,
which also uses the token dllimport, but is not at all related.