Bo Yang <[EMAIL PROTECTED]> wrote: > In c, we can LoadLibrary, GetProccAddress, but with C++, how is there > a way to export one entire class in a dll?
XPCOM DLL exports a single function named NSGetModule. By calling this function you get nsIModule interface pointer. You can then call nsIModule::getClassObject to get nsIFactory implementation. Finally you can call nsIFactory::CreateInstance to get an interface pointer of the actual object. You don't usually make these calls by hand. You use higher level facilities provided by XPCOM glue code, which perform these low-level manipulations under the hood. Note that a class implementing an XPCOM interface doesn't need to be exported from the DLL in order to be usable. An XPCOM interface is a class with all methods pure virtual: internally, an interface pointer is a pointer to so called vtable, which in turn is just an array of function pointers. Each function pointer points to an implementation of one interface method. This way, the compiler can generate a method call without having to resolve any names, either at link time or runtime. It just knows at compile time that it needs to retrieve, say, fifth function pointer from the vtable and call that (information that can be derived from headers alone). > The above code use use GetServiceByContractID to get a pointer to > nsIServiceCookie class which indeed in another dll. nsIServiceCookie is an abstract class with all methods pure virtual. This class itself has no machine code behind it (a class derived from it might, of course). In what sense is this class located in another DLL? What bits exactly do you believe are in that DLL? > Now, take a little > more deep consideration, we didn't have the import library for that > dll, so why the code cookiemanager->Remove get passed in linking > stage? The compiler does not generate any external symbol references for this call. Linker never even knows about it. > In linking stage, there are two situation for an unresolved > symbol, either it will be found in another object file or it must be > marked as a need-import symbol in the final exe and get linked in > program loading stage. ... or no symbol is used at all. > And in this condition, absolutely it will use > the second method. No, it absolutely won't. > Finally, I came across an idea, this behaviour may has something to do > with the C++ virtual dispatching. Bingo. > And this also mean that, we > never can call a non-virtual method in xpcom programming. XPCOM deals with interfaces. Interfaces don't have non-virtual methods. So of course you can't call one. Igor Tandetnik _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
