Menu
▾
▴
mingw-users
|
From: Roman W. <rom...@gm...> - 2011-06-20 09:55:37
|
Dear mingw team.
I have noticed that vtables generated by mingw are different than
those from visualstudio.
The incompatible code is generated by such class.
class Vtable {
virtual void Overloaded(int) = 0;
virtual void Overloaded(Vtable&) = 0;
virtual void Other() = 0;
};
According to what i found here:
http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html
I have made my code compatible using such prepossessing.
class Vtable {
#ifdef __GNU__
virtual void Overloaded(Vtable&) = 0;
virtual void Overloaded(int) = 0;
#else
virtual void Overloaded(int) = 0;
virtual void Overloaded(Vtable&) = 0;
#endif
virtual void Other() = 0;
};
It is not an example of code I use, but same trick has helped in my problem.
I use miingw 4.4, and the becomes compatible with what visual studio
6.0 generates, and as i believe with the newer versions of vs.
Is there some compiler option so ming would generate vs compatible vtables?
Maybe there is some other way to make a code compatible, some
preprocessor macro probably like:
class Vtable __gcc_make_MSC_vtables_
{
virtual void Overloaded(int) = 0;
virtual void Overloaded(Vtable&) = 0;
virtual void Other() = 0;
};
Any way I think the problem should be described some where on
http://www.mingw.org/wiki.
|
|
From: Earnie <ea...@us...> - 2011-06-20 11:45:00
|
Roman Wieczorek wrote: > > Any way I think the problem should be described some where on > http://www.mingw.org/wiki. > You might think to look at http://mingw.org/wiki/MixingCompilers and if it needs modified see http://mingw.org/wiki/MinGWiki_Pages for help with that. -- Earnie -- http://www.for-my-kids.com |
|
From: Chris W. <ch...@qw...> - 2011-06-20 12:38:04
|
Hi Roman,
On Mon, 20 Jun 2011, Roman Wieczorek wrote:
> I have noticed that vtables generated by mingw are different than
> those from visualstudio.
> The incompatible code is generated by such class.
>
> class Vtable {
> virtual void Overloaded(int) = 0;
> virtual void Overloaded(Vtable&) = 0;
> virtual void Other() = 0;
> };
>
> According to what i found here:
> http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html
> I have made my code compatible using such prepossessing.
As far as I know, the only cross-compiler (standard, supported) use of
vtables is in COM APIs, and as that discussion concluded, COM does not
allow overloading of methods:
"Overloading methods isn't supported by COM. The MIDL compiler won't let
you define an interface with two methods that have same name."
So what is this application of vtables that you're using? If it's COM, is
it an incorrect use of the standard (both in overloading and its use of
references)? Whatever it is, is it sufficiently standardised that you're
actually allowed to mix compilers when using it?
> Is there some compiler option so ming would generate vs compatible
> vtables?
I doubt it, this is the first time I've heard of someone wanting to do
something that involved mixing compilers and not COM and that might not be
prohibited by lack of standardisation between C++ compilers. But you could
ask the GCC developers about adding such an option.
> Maybe there is some other way to make a code compatible, some
> preprocessor macro probably like:
I'm not sure how a simple macro could affect the order that methods are
compiled into a vtable, at least not like that. Perhaps, just possibly, it
might work if it was a variadic macro that is applied to the methods in
question within the class, changing their order.
> Any way I think the problem should be described some where on
> http://www.mingw.org/wiki.
If you do, please describe your use case as well. (what standard you're
adhering to, etc.)
Cheers, Chris,
|
|
From: Roman W. <rom...@gm...> - 2011-06-20 14:00:05
|
I create a dll for an MT4 server, which is compiled with msc, microsoft compiler. It is not a COM. The system dynamically loads libraries by LoadLibrary (from windows api). The dll requirements are defined by single c++ header file with the definitions of exported functions, structures and classes. The producer directly says that dll needs to be compiled visual studio 6.0 - yes i know what it means, do not point this sentence. But the loading system is made VERY good. There are no exception, memory ownage does not pass between binaries. And all but one object, passing in the api, are pure C structs. I gave it a try. I have fixed the header for compatibility with name mangling, structure alignment, and some predefined windows types like __int64. I was really but surprised but everything worked. Did the mingw developers made things compatible? Seem so. I was not aware about overloading problem. Till I called one of such methods. This page says there are problems http://chadaustin.me/cppinterface.html but, here is the description of a problem http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html. They tell about COM's but also say how the difference looks like - note the difference of the example and the one i posted. Once again gave it a try. With preprocessor macro querying which compiler is used. IT WORKED. Since I was able to get things together by so easy change, I also must miss something, and there is probably a compiler switch which does the same. I hadn't find such switch. OK I described the fix that worked for me, probably some one will find it useful in his issue. Thanks for help - I just wanted to be sure that there is no standard method for sharing overloaded methods. 2011/6/20 Chris Wilson <ch...@qw...>: > Hi Roman, > > On Mon, 20 Jun 2011, Roman Wieczorek wrote: > >> I have noticed that vtables generated by mingw are different than >> those from visualstudio. >> The incompatible code is generated by such class. >> >> class Vtable { >> virtual void Overloaded(int) = 0; >> virtual void Overloaded(Vtable&) = 0; >> virtual void Other() = 0; >> }; >> >> According to what i found here: >> http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html >> I have made my code compatible using such prepossessing. > > As far as I know, the only cross-compiler (standard, supported) use of > vtables is in COM APIs, and as that discussion concluded, COM does not > allow overloading of methods: > > "Overloading methods isn't supported by COM. The MIDL compiler won't let > you define an interface with two methods that have same name." > > So what is this application of vtables that you're using? If it's COM, is > it an incorrect use of the standard (both in overloading and its use of > references)? Whatever it is, is it sufficiently standardised that you're > actually allowed to mix compilers when using it? > >> Is there some compiler option so ming would generate vs compatible >> vtables? > > I doubt it, this is the first time I've heard of someone wanting to do > something that involved mixing compilers and not COM and that might not be > prohibited by lack of standardisation between C++ compilers. But you could > ask the GCC developers about adding such an option. > >> Maybe there is some other way to make a code compatible, some >> preprocessor macro probably like: > > I'm not sure how a simple macro could affect the order that methods are > compiled into a vtable, at least not like that. Perhaps, just possibly, it > might work if it was a variadic macro that is applied to the methods in > question within the class, changing their order. > >> Any way I think the problem should be described some where on >> http://www.mingw.org/wiki. > > If you do, please describe your use case as well. (what standard you're > adhering to, etc.) > > Cheers, Chris, > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > |
|
From: Chris W. <ch...@qw...> - 2011-06-20 14:23:04
|
Hi Roman, On Mon, 20 Jun 2011, Roman Wieczorek wrote: > I create a dll for an MT4 server, which is compiled with msc, microsoft > compiler. It is not a COM. The system dynamically loads libraries by > LoadLibrary (from windows api). The dll requirements are defined by > single c++ header file with the definitions of exported functions, > structures and classes. If it's a C++ header file then probably it is subject to all kinds of undocumented grey areas in the standard, which means that future versions of Visual Studio might well be incompatible with it, as well as all other C++ compilers (MinGW, Watcom, Borland...) > I have fixed the header for compatibility with name mangling, structure > alignment, and some predefined windows types like __int64. I was really > but surprised but everything worked. Did the mingw developers made > things compatible? Seem so. I guess that given all the effort you had to go to, you probably hit most of the grey areas in the standard. It's hard for any C++ compilers to be more different than CL and GCC are. But there might be gotchas lurking still, like exception handling... > I was not aware about overloading problem. Till I called one of such > methods. Is it possible for you to give the overloaded methods unique names to work around this? (so that they're no longer overloaded) Also, it seems that the application developers, who have tried pretty hard to make this portability possible, might have missed something with the overloading, and they might wish to correct it in future versions, by not using overloading. Cheers, Chris. |
|
From: Roman W. <rom...@gm...> - 2011-06-21 08:39:42
|
> If it's a C++ header file then probably it is subject to all kinds of
> undocumented grey areas in the standard,
I find many header directives making things compatible. Like:
"#pragma pack(push,1)" __stdcall "extern C", abstract C++ classes
(only pure virtuals methods)
> which means that future versions
> of Visual Studio might well be incompatible with it, as well as all other
> C++ compilers (MinGW, Watcom, Borland...)
I do not believe Microsoft guys would make things incompatible to them
self, they used to follow their own history.
I feel the spirit of MinGW and gcc-cross-compilation is to give an
alternative, so they probably will not remove to much of
compatibility.
> Is it possible for you to give the overloaded methods unique names to work
> around this? (so that they're no longer overloaded)
Yes:
class Vtable {
#ifdef __GNU__
virtual void Overloaded(Vtable&) = 0;
virtual void Overloaded(int) = 0;
#elif _MSC_VER //microsoft compiler
virtual void Overloaded(int) = 0;
virtual void Overloaded(Vtable&) = 0;
#endif
virtual void Other() = 0;
};
generates same virtual tables as
class Vtable {
//order used by gcc
virtual void Overloaded1(Vtable&) = 0;
virtual void Overloaded2(int) = 0;
virtual void Other() = 0;
};
for both MinGw and visual studio express
Thank you much, it makes things simpler and generaly works for
"preprocessor macro" i was looking for.
Even if it works only due to grey areas of vtable generation.
|
|
From: Earnie <ea...@us...> - 2011-06-21 12:31:32
|
Roman Wieczorek wrote: >> which means that future versions >> of Visual Studio might well be incompatible with it, as well as all other >> C++ compilers (MinGW, Watcom, Borland...) > > I do not believe Microsoft guys would make things incompatible to them > self, they used to follow their own history. > I feel the spirit of MinGW and gcc-cross-compilation is to give an > alternative, so they probably will not remove to much of > compatibility. I think you missed the point. It isn't Microsoft specific, it is the nature of C++ specifications such that every new compiler version is likely to break compatibility of assumptions made in the grey areas of the specification. -- Earnie -- http://www.for-my-kids.com |
