Re: new-ing an exported class
"ben" <brm@morrisb.fsnet.co.uk> wrote in message
news:1163514453.216911.130480@f16g2000cwb.googlegroups.com...
:-)
So If CFoo is a class that is exported from A.dll and B.exe links to
A.dll's import lib then A.dll is loaded explicitly by B.exe, I think
that all CFoo's function implementations still reside in A.dll.
B.exe then new's an instance of the exported CFoo, so B's heap manager
creates a new CFoo (the data) but the function impl. is still residing
in A.dll.
B.exe calls CFoo->CreateAnotherFoo() which new's up another instance of
CFoo.
I think CreateAnotherFoo() has invoked A.dll's "new" because that's
where the function implementation resides i.e. in A.dll.
Does that sound right then?
Yeah, sounds like you understand it... but that's a bad idea because now
some Foos are on the A heap and some on the B heap. Best is to NOT export
classes at all, provide a common interface (virtual member functions) in a
public header file, and let A dllexport a CreateFoo function (usually extern
"C" as well) that does new Foo. Then all Foo objects exist only within
A.dll, and B sees only the IFoo interface. Foos can create more Foos and
delete them again, they are all in the A.dll heap, and life is good.
This is kinda a lightweight version of what COM (Component Object Model)
does, but without the IDL, registry entries, guids, coclasses, factories,
marshalling, etc, etc, required for language independence and inter-process
communication. If you use this lightweight architecture to begin with, it
will make it easier to move to COM if you ever do need any of those extra
features.
One of the things from COM that you probably do want to borrow right away is
reference-counting, because it's so easy to implement if you do it up front.
Igor Tandetnik wrote:
"ben" <brm@morrisb.fsnet.co.uk> wrote in message
news:1163509761.325089.188120@m73g2000cwd.googlegroups.com
If I create an object on the heap by calling new() in an .exe then the
.exe's heap manager creates the object. If I call new() in a DLL then
the DLL's heap manager creates the object for me. What happens if I
create an object on the heap in an exe then pass an object reference
to a DLL that calls a method on the object that calls new(). Which
heap manager creates the object, i.e. the exe's or the dll's?
That depends on where the implementation of the method resides.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925