Re: [Dev-C++] RE: [Mingw-users] dlls and classes

[Per W. <pw...@ia...>]

Different compilers aren't forced to use the same location of the virtual
table pointer, and same order of the entries of the table. Also, some
compilers encodes extra information into the virtual table, such as object
size etc.

I haven't worked anything with COM, but I would assume that you have to
use specific compiler flags or pragmas or extra attributes to tell the
compiler that it must a normalzied way of declaring the virtual method
table.

/Per W

On Fri, 15 Nov 2002, Weiqi Gao wrote:

> Carlos Garc=EDa del Monte wrote:
> >
> > [...]
> > Searching for some things I found at=20
> > http://www.gamecoding.co.uk/tutorials,
>=20
> Error 404 Not found.  Is the URL correct?
>=20
> > [...]
> > 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".
>=20
> 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
> > [...]
> >=20
> > I see the idea, but it works? I didn't see it very clear.
>=20
> 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.
>=20
> 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."
>=20
> (If the above long URL is broken in transit, try this
> http://tinyurl.com/2q8g).
>=20
> > 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?
>=20
> 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();
>=20
> into something similar to what is generated by
>   ((p->vtbl) + 0)();
>   ((p->vtbl) + 1)();
>   ((p->vtbl) + 2)();
>=20
> where vtbl is the virtual function table pointer of the implementation
> class.
>=20
> 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.
>=20
> > [...]
> > 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.
>=20
> 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.
>=20
> --
> Weiqi Gao
> wei...@ne...
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www.noicys.cjb.net/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>=20