binary-compatibility

Could someone explain to me why adding a virtual function to the end of a class declaration avoids binary incompatibility? If I have: class A { public: virtual ~A(); virtual void someFuncA() = 0; virtual void someFuncB() = 0; virtual void other1() = 0; private: int someVal; }; And later modify this class declaration to: class A { public: virtual ~A(); virtual void someFuncA() = 0; virtual void someFuncB() = 0; virtual void someFuncC() = 0; virtual void other1() = 0; private: int someVal; }; I get a coredump from another .so compiled against the previous declaration. But if I put someFuncC() at

Let's say I write a DLL in C++ and would like to export a method which takes a std::vector parameter. Can I hope for any binary compatibility between different STL versions? If you mean between the versions included with updated versions of the same compiler, yes, it can (and will) work in some cases, but you have to be careful. There are also a few special cases, such as the Intel and Microsoft compilers on Windows -- Intel is pretty careful to maintain binary compatibility, and at least when I've tried it, it's always worked quite nicely. For most other cases, the answer is no. I'm not aware

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 parent class. Will this require a re-compile? // before public class B extends A{ protected void x(){}; } /

https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=vs-2017 says that C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017 is guaranteed except: 1)When static libraries or object files are compiled with the /GL compiler switch. 2)When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12. Also, binary compatibility only exists between

STL Binary Interfaces I'm curious to know if anyone is working on compatible interface layers for STL objects across multiple compilers and platforms for C++. The goal would be to support STL types as first-class or intrinsic data types. Is there some inherent design limitation imposed by templating in general that prevents this? This seems like a major limitation of using the STL for binary distribution. Theory - Perhaps the answer is pragmatic Microsoft has put effort into .NET and doesn't really care about C++ STL support being "first class". Open-source doesn't want to promote binary-only