Refering to Class, Types, and Functions from Dlls

**=?Utf-8?B?UGV0ZXIgUml0Y2hpZSBbQyMgTVZQXQ==?=** · May 27 '07, 03:25 PM

RE: Refering to Class, Types, and Functions from Dlls

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

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#

"safaci2000@gma il.com" wrote:

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?
>
--
Samir
>
>

**Ben Voigt** · May 28 '07, 02:35 PM

Re: Refering to Class, Types, and Functions from Dlls

"Peter Ritchie [C# MVP]" <PRSoCo@newsgro ups.nospamwrote in message
news:A42B68DA-C94A-4545-9544-422A9DE25181@mi crosoft.com...

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 DllRegisterServ er function
and call it, making Windows aware of the coclass, and then use
CoCreateInstanc e to create an instance of the class, probably using the
com_ptr compiler support.

>
--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#
>
>
"safaci2000@gma il.com" wrote:
>

>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.Hos t 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?
>>
>--
>Samir
>>
>>

**Peter Nimmo** · Jun 12 '07, 05:15 PM

Re: Refering to Class, Types, and Functions from Dlls

"Ben Voigt" <rbv@nospam.nos pamwrote in
news:e8hmnTToHH A.4552@TK2MSFTN GP04.phx.gbl:

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]** · Jun 12 '07, 05:25 PM

Re: Refering to Class, Types, and Functions from Dlls

"Peter Nimmo" <PeterNimmo@new sgroups.nospamw rote in message
news:Xns994DB82 BF5475PeterNnos pamtnsofres@127 .0.0.1...

"Ben Voigt" <rbv@nospam.nos pamwrote in
news:e8hmnTToHH A.4552@TK2MSFTN GP04.phx.gbl:
>

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

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

**Peter Nimmo** · Jun 12 '07, 05:45 PM

Re: Refering to Class, Types, and Functions from Dlls

"Ben Voigt [C++ MVP]" <rbv@nospam.nos pamwrote in
news:O2nD1TRrHH A.1168@TK2MSFTN GP03.phx.gbl:

>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

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.

**=?Utf-8?B?UGV0ZXIgUml0Y2hpZSBbQyMgTVZQXQ==?=** · Jun 12 '07, 05:55 PM

Re: Refering to Class, Types, and Functions from Dlls

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

"Ben Voigt" wrote:

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 DllRegisterServ er function
and call it, making Windows aware of the coclass, and then use
CoCreateInstanc e to create an instance of the class, probably using the
com_ptr compiler support.

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#

**Ben Voigt [C++ MVP]** · Jun 13 '07, 05:25 PM

Re: Refering to Class, Types, and Functions from Dlls

"Peter Nimmo" <PeterNimmo@new sgroups.nospamw rote in message
news:Xns994DBCC 85C0C6PeterNnos pamtnsofres@127 .0.0.1...

"Ben Voigt [C++ MVP]" <rbv@nospam.nos pamwrote in
news:O2nD1TRrHH A.1168@TK2MSFTN GP03.phx.gbl:
>

>>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

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(dlli mport) 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]** · Jun 13 '07, 05:25 PM

Re: Refering to Class, Types, and Functions from Dlls

"Peter Ritchie [C# MVP]" <PRSoCo@newsgro ups.nospamwrote in message
news:BF8D7999-806D-420D-8E72-A0BD0E80F043@mi crosoft.com...

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

You can't.

I was speaking about __declspec(dlli mport), not
System::Runtime ::InteropServic es::DllImportAt tribute

>
>
"Ben Voigt" wrote:

>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 DllRegisterServ er function
>and call it, making Windows aware of the coclass, and then use
>CoCreateInstan ce to create an instance of the class, probably using the
>com_ptr compiler support.

>
--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#
>
>

**=?Utf-8?B?UGV0ZXIgUml0Y2hpZSBbQyMgTVZQXQ==?=** · Jun 13 '07, 06:05 PM

Re: Refering to Class, Types, and Functions from Dlls

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.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#

"Ben Voigt [C++ MVP]" wrote:

>
"Peter Ritchie [C# MVP]" <PRSoCo@newsgro ups.nospamwrote in message
news:BF8D7999-806D-420D-8E72-A0BD0E80F043@mi crosoft.com...

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

>
You can't.
>
I was speaking about __declspec(dlli mport), not
System::Runtime ::InteropServic es::DllImportAt tribute
>

"Ben Voigt" wrote:

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 DllRegisterServ er function
and call it, making Windows aware of the coclass, and then use
CoCreateInstanc e to create an instance of the class, probably using the
com_ptr compiler support.

**Ben Voigt [C++ MVP]** · Jun 14 '07, 05:35 AM

Re: Refering to Class, Types, and Functions from Dlls

"Peter Ritchie [C# MVP]" <PRSoCo@newsgro ups.nospamwrote in message
news:0F68EC58-38A6-4D53-903C-6FC6AD53DF45@mi crosoft.com...

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(dlli mport), 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.

>
--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.

Redirecting…

http://www.peterRitchie.com/blog/

Microsoft MVP, Visual Developer - Visual C#
>
>
"Ben Voigt [C++ MVP]" wrote:
>

>>
>"Peter Ritchie [C# MVP]" <PRSoCo@newsgro ups.nospamwrote in message
>news:BF8D799 9-806D-420D-8E72-A0BD0E80F043@mi crosoft.com...

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

>>
>You can't.
>>
>I was speaking about __declspec(dlli mport), not
>System::Runtim e::InteropServi ces::DllImportA ttribute
>>

>
>
"Ben Voigt" wrote:
>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 DllRegisterServ er
>function
>and call it, making Windows aware of the coclass, and then use
>CoCreateInstan ce to create an instance of the class, probably using
>the
>com_ptr compiler support.

>

Refering to Class, Types, and Functions from Dlls

Refering to Class, Types, and Functions from Dlls

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment