|
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 > |