Refering to Class, Types, and Functions from Dlls

  • Thread starter Thread starter safaci2000
  • Start date Start date
S

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?
 
If it's a native app (not managed) then you simply include the header file of
the type you want to reference.
 
Peter Ritchie said:
If it's a native app (not managed) then you simply include the header file
of
the type you want to reference.
Click to expand...

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.
 
Trying to dllimport native C++ classes is a bad idea which will cause
you no end of trouble down the road.
Click to expand...
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
 
Peter Nimmo said:
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.
Click to expand...

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?
 
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?
Click to expand...
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.
 
Peter Nimmo said:
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.
Click to expand...

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.
 
Peter Ritchie said:
How can you DllImport a native C++ class in managed code?
Click to expand...

You can't.

I was speaking about __declspec(dllimport), not
System::Runtime::InteropServices::DllImportAttribute
 
Peter Ritchie said:
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...
Click to expand...

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.
 
Back
Top