Some doubts on DLLs

Hello, I'm almost new on working with Dlls, I've read most but I have some questions.

1) the functions in a Dll can access to the global memory of the calling application; true?
2) as an exe, the dlls can have a global data space, which is lost every time a called function exits, true?
3) many doubts about dlls and objects..can a dll contain "objects"? I'm explaining, if I can...let's say I have an exported function as following:

Code:

---

MyClass* CreateMyClassObject( LPVOID params )
{
    return new MyClass(params);
}

---

the implementation of MyClass is compiled in the dll. Now, my program creates a MyClass object loading the library, say myClass.dll, and creating the object:

Code:

---

...
LoadLibrary( _T("MyClass.dll"));
pFuncCreate = GetProcAddress( "CreateMyClassObject");
MyClass *p = (*pFuncCreate)( NULL );

---

now, the object is created in the heap, so the members are all accessible, but what about the methods? Is the library somehow called every time I access to a method of MyClass?

I'm sorry if you find many errors on fundamentals of dlls, please advise me on all those errors, because there's something fundamental I think I don't know about dlls...

Thank you all,

BrownB

Quote:

---

Originally Posted by BrownB

1) the functions in a Dll can access to the global memory of the calling application; true?

---

True. The DLLs become part of the application when they are loaded.

Quote:

---

2) as an exe, the dlls can have a global data space, which is lost every time a called function exits, true?

---

Not true. What is a "global data space", and why would it be lost on function return, if it's global?

Quote:

---

3) many doubts about dlls and objects..can a dll contain "objects"?

---

Yes, but with restrictions. In particular, your example below doesn't work.

At least for MSVC++, the following rules apply: for normal C++ usage of objects, you must link statically against the DLL containing the class (as in, link against its import library). You cannot use LoadLibrary and GetProcAddress. The reason is that every method of the class is a function, and you'd have to GetProcAddress every single one of these functions. Aside from being tiresome (you'd have to find out the mangled name of the functions, to start with), this also simply doesn't work with object syntax.
The class must (or at least should, not sure) have the __declspec(dllexport) attribute when compiling the DLL; the class definition (its header) must be also available to the main program and have the attribute __declspec(dllimport) there. Use preprocessor magic to make the switch. You've probably seen it already for functions.

The alternative is used by COM. You can use pure interfaces containing only virtual, abstract functions. The definition of the interface must be available to the main program. It can then use the interface, LoadLibrary a DLL, GetProcAddress a factory function that returns a pointer to this interface and call it. You can use the resulting interface, because the vtable of the class contains the addresses of all necessary functions.
However, you can NOT delete this interface pointer. Because of at least three reasons I can think of, it must be the DLL deleting the object. One way is to export a deleter function from the DLL and calling that, but probably a better way is to follow COM's lead and let the objects reference-count themselves. Then they can delete themselves when the count drops to zero.
In fact, it might not be a bad idea, if you really want to load the DLL dynamically, to write a proper COM object. It isn't that much additional work, and you gain the support of the whole infrastructure that's in place.