Christian Biesinger :
> Igor Tandetnik wrote:
>> No, that would be static linking. Dynamic linking involves LoadLibrary
>> and GetProcAddress API calls
>
> No, both are dynamic linking. With static linking, no DLL files are
> involved at all, only static libraries, and only at link time, not at
> run time.
In c, we can LoadLibrary, GetProccAddress, but with C++, how is there a
way to export one entire class in a dll? Even we can achieve this, but
without link into the dll file at link time, there is still no way to
use the the class in dll.
There is the code which let me to get into deep thinking:
nsCOMPtr<nsIServiceManager> servMan;
nsresult rv = NS_GetServiceManager(getter_AddRefs(servMan));
if (NS_FAILED(rv))
return -1;
nsCOMPtr<nsICookieManager> cookieManager;
rv = servMan->GetServiceByContractID("@mozilla.org/cookiemanager",
NS_GET_IID(nsICookieManager), getter_AddRefs(cookieManager));
if (NS_FAILED(rv))
return -1;
PRUint32 len;
deletedCookies->GetLength(&len);
for (int c=0; c<len; c++)
cookiemanager->Remove(deletedCookies[c].host, //Here, the call
deletedCookies[c].name,
deletedCookies[c].path);
The above code use use GetServiceByContractID to get a pointer to
nsIServiceCookie class which indeed in another 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? 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. And in this condition, absolutely it will use the second method.
But, without any call to LoadLirary and any import library, why this
code pass link?
Finally, I came across an idea, this behaviour may has something to do
with the C++ virtual dispatching. I mean, with the virtual method, C++
compiler generate codes with different way used for a non-virtual
funtion. It needn't to know exactly where the method locate in the
memory, neither it can do this. So, here, when cookiemanager->Remove,
there is no need to find where Remove method is, because it is a virtual
function. And this explain why the above code and compile and link
successfully without any error. And this also mean that, we never can
call a non-virtual method in xpcom programming.
Am I right?
_______________________________________________
dev-tech-xpcom mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
