[Dev-C++] RE: [Mingw-users] dlls and classes
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Weiqi G. <wei...@ne...> - 2002-11-15 16:38:47
|
Carlos Garc=EDa del Monte wrote: > > [...] > Searching for some things I found at=20 > http://www.gamecoding.co.uk/tutorials, Error 404 Not found. Is the URL correct? > [...] > it defines a pure=20 > virtual class and a function for creating a instance of the=20 > object which returns a pointer to it and is declared as=20 > extern "C". This sounds like the approach of COM. The first chapter of Don Box's Essential COM is devoted to explaining this approach. In COM terms, the "public" class an interface, and the "private" class is the implementation. > [...] >=20 > I see the idea, but it works? I didn't see it very clear. Yes it does. I was asking the same questions 8 years ago, and had the good fortune of having my questions answered by Charles Kindel, the COM Guy at Microsoft. http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3Dutf-8&threa= dm=3D01bb 93ce%248f66b6c0%243016369d%40ckindel-610&rnum=3D3&prev=3D/groups%3Fq%3DCh= arl ie%2BKindel%2BWeiqi%2BGao%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26 selm%3D01bb93ce%25248f66b6c0%25243016369d%2540ckindel-610%26rnum%3D3 Google Groups: View Thread "C or C++ for OLE interface implementation." (If the above long URL is broken in transit, try this http://tinyurl.com/2q8g). > My thought was that it avoids the problem when calling the=20 > creating function of the dll, but at the end you will have to=20 > use the member functions, and those will have to be compiled=20 > there by the compiler which built the dll, haven't them the=20 > mangling which generates the problems? Not with pure virtual functions. All compilers, gcc included now, compile // I is the interface with pure virtual functions // I *p =3D give_me_an_I(); p->first_function(); p->second_function(); p->third_function(); into something similar to what is generated by ((p->vtbl) + 0)(); ((p->vtbl) + 1)(); ((p->vtbl) + 2)(); where vtbl is the virtual function table pointer of the implementation class. In other words, pure virtual functions calls compiles into pointer manipulations rather than name look ups. And all compilers do the pointer manipulation the same way, even though they do the name mangling differently. > [...] > So my supposition=20 > about code mangling of the class functions are erroneous,=20 > what happens is that code mangling matters only for exported=20 > functions, not for the other which are yet inside the dll.=20 > And that's the reason why it works. This is not correct. See above. And read Charlie Kindel's response. The reason is *pure virtual* functions and the way they are compiled by *all* the popular Windows compilers. -- Weiqi Gao wei...@ne... |