Re: crossing dll boundary ...
- From: "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 11 Jan 2007 04:37:04 -0800
"JD" <jdt_young@xxxxxxxxx> wrote in message
news:e1VVWWPNHHA.5016@xxxxxxxxxxxxxxxxxxxxxxx
Hello Robert,
Thank you for your answer. My case is dynamic linking. I guess it won't
may a difference. The compiler should be smart enough to place the member
variables in dll Main during the compile time. But during the run time,
if any of the class's functions calls another function in dll A, execution
still needs to jump into the dll A's image. Is that right?
I would guess you are static linking DllA to Dll main... this means you link
Dll main with the DllA.lib import lib. This is called static linking.
Dynamic linking if calling LoadLibrary/GetProcAddress instead. These don't
work with exported functions. The only way AFAIK to use exported classes in
another DLL is to statically link.
Anyway, since both DLL's are loaded into the same process, the class is
instantiated in the process heap. I think this heap is used by all DLL's
and doesn't "belong" to any one DLL. So the "m" member data is stored in
the process heap.
The member functions are exported functions in DllA. They reside in DllA.
If you call them from Dll main, it is an indirect call through a function
pointer in the IAT (import address table) for the DLL. So technically, it
is an extra level of indirection to call an exported function. Nowadays
this level of indirection is considered insignificant. So I think you are
fine the way it is.
-- David (MVP)
.
- Follow-Ups:
- Re: crossing dll boundary ...
- From: David Wilkinson
- Re: crossing dll boundary ...
- From: David Ching
- Re: crossing dll boundary ...
- References:
- crossing dll boundary ...
- From: JD
- Re: crossing dll boundary ...
- From: robert
- Re: crossing dll boundary ...
- From: JD
- crossing dll boundary ...
- Prev by Date: How do i change "File", "Edit", "View", and "Help" menu text?
- Next by Date: Re: How to load JPEG File anf read it pixel by pixel
- Previous by thread: Re: crossing dll boundary ...
- Next by thread: Re: crossing dll boundary ...
- Index(es):
Relevant Pages
|