binary-compatibility

问题 When refactoring methods it is easy to introduce binary incompabilities (with previous versions of the code) in Java. Consider changing a method to widen the type of its parameter to a parent interface: void doSomething(String x); // change it to void doSomething(CharSequence c); All the code that uses this method will continue to compile without changes, but it does require a re-compile (because the old binaries will fail with a MethodNotFoundError). How about pulling a method up into a

问题 When refactoring methods it is easy to introduce binary incompabilities (with previous versions of the code) in Java. Consider changing a method to widen the type of its parameter to a parent interface: void doSomething(String x); // change it to void doSomething(CharSequence c); All the code that uses this method will continue to compile without changes, but it does require a re-compile (because the old binaries will fail with a MethodNotFoundError). How about pulling a method up into a

问题 Now, I know it is generally bad to add new virtual functions to non-leaf classes as it breaks binary compatibility for any derived classes which haven't been recompiled. However, I have a slightly different situation: I have an interface class and implementation class compiled into a shared library, for example: class Interface { public: static Interface* giveMeImplPtr(); ... virtual void Foo( uint16_t arg ) = 0; ... } class Impl { public: ... void Foo( uint16_t arg ); .... } My main

问题 I have been looking around for an ABI cross-check tool. Now I have met some of the tools suggested in other questions, such as in these questions: How to test binary compatibility automatically? Static analysis tool to detect ABI breaks in C++ Now, this is not exactly what I am trying to do - as these track ABI changes between versions. I was wondering that given project source files + library header file and library .so file, as well as a compiler version (which is used for compiling both

问题 Suppose we have the class X in version 1 of the assembly A.dll : class X { SomeType Property { set; get; } } and then in version 2 of the assembly A.dll : class X { SomeType Property { set; get; } SomeType OtherProperty { set; get; } } Now suppose we have a second assembly B.dll that loads A.dll and uses X. Will the addition of the property OtherProperty break the ABI? Will B.dll fail to use A.dll / X ? If not, would the order of the declarations make any difference? If the properties had

问题 Hope this question isn't going to be too vague. Reading through the COM spec and Don Box's Essential COM book, there is plenty of talk of the "problems that COM solves" - and they all sound important, relevant and current. So how are the problems that COM addresses dealt with on other systems (linux, unix, OSX, android)? I'm thinking of things like: binary compatibility across compilers and compiler versions binary component reuse compiling an application such that it has run-time

问题 Let's go straight to it : Old code : public interface IFoo {} public class Foo : IFoo {} ... public static IFoo Bar() { return new Foo(); } New code : public static Foo Bar() { return new Foo(); } Obviously there should be no problem here, everything you were doing on the old return type, you can still do on the new return type, any is , as or cast should behave the same as before... So did I break binary compatibility, or can I just release it as a minor version without bothering users ? 回答1

问题 TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way , while I'd assumed it is necessarily two-way. Where's the catch? First, for background: Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017. Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat) The official documentation site states a confusing restriction . Background / related Questions: Is Visual-C++-2017

问题 I originally designed a win32 application on win7 32bits, with VC9.0. I recently upgraded to win7 64 bits, and tried to build+execute the previous application. Building runs fine (win32 application), but on runtime I get the error "[...] has exited with code -1073741701 (0xc000007b)." I guess this results of the loading of a 64bits version of an [intended] 32bits dll. Specific dependencies for this project are: SDL.lib SDLmain.lib SDL_ttf.lib opengl32.lib glu32.lib wininet.lib SDL and SDL_ttf

问题 I originally designed a win32 application on win7 32bits, with VC9.0. I recently upgraded to win7 64 bits, and tried to build+execute the previous application. Building runs fine (win32 application), but on runtime I get the error "[...] has exited with code -1073741701 (0xc000007b)." I guess this results of the loading of a 64bits version of an [intended] 32bits dll. Specific dependencies for this project are: SDL.lib SDLmain.lib SDL_ttf.lib opengl32.lib glu32.lib wininet.lib SDL and SDL_ttf