On 1/30/14, Jens Alfke <j...@mooseyard.com> wrote: > > On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas <devli...@shadowlab.org> > wrote: > >> It is barely possible to create a stable ABI in C++. This language suffers >> all possible form of fragile base class problem: >> Add a new ivar, all subclasses and stack allocated objects are broken. >> Add a new virtual method, you break all virtual subclasses. > > Exactly. Also, the use of templates or inline methods in library classes > will cause library code to get built into the calling app at compile time. > After that, the library has to be very careful not to break compatibility > with such code to avoid breaking the app. A typical obvious example is > changing the implementation of an inline method; newly compiled apps will > get the new behavior but existing apps will keep the old behavior since the > inlined code is in the app not the library. That's bad news if the old > inline method accesses private state of the old version of the class that no > longer exists in the same form in the new version. > > It is possible to create binary-compatible C++ APIs but you have to be very, > very careful -- generally there are a lot of rules about the use of inlines > and templates; you have to add placeholder data members and virtual methods > to classes to reserve room for future expansion, etc. > > --Jens
And there's more... The compilers can do name mangling differently, so if you switch compilers or change the version of the same compiler, there is a chance that the binaries won't be compatible. And to re-iterate on what Jens just said, this kind of problem gets intertwined with the C++ standard library. This generally means you can't mix standard libraries and potentially different versions of the same standard library. Android is one of the best (worst?) examples of this. Android makes developers choose from 3-4 different compiler versions (multiple versions of gcc and clang), and then also makes you pick which C++ standard library you want to use (a minimal Android one, STLport, GNU, and potentially the new clang one). All of these are incompatible so you can't mix and match. 4x4 means you have 16 ways you can blow up your code. Static linking and only exposing extern C APIs can help in some cases, but more often than not, I've dealt with people/libraries/SDKs who don't understand this (but really need to) and they are not doing this which has forced me to work around all sorts of bad situations. And I've already encountered people who've run into the same problem on Mac/iOS with libstdc++ and libc++ because they didn't understand this. I've been fortunate that most of the stuff I've dealt with doesn't use C++ exceptions because I think that is another headache area. As for rules, I don't know any centralized place. The problem is that C++ is so complex and ABI stability is not a goal. In addition, some rules/behaviors are not obvious on how things will be impacted. One example issue that caught both me and Apple off-guard was during the 10.5 time frame, Apple redefined GLenum trying to get stuff 64-bit ready. Under 32-bit, the GLenum type was changed from long (in 10.4 and before) to int (in 10.5). Under 32-bit, sizeof(long) == sizeof(int) == 4-bytes. (In 64-bit, sizeof(long) == 8-bytes, sizeof(int) == 4-bytes) So in C 32-bit, binary compatibility is preserved and this is perfectly fine to do which is why the change was okayed. But under C++, even though both types are 4-bytes under 32-bits, the gcc/C++ name mangling treat int and long as fundamentally different types. Thus binary compatibility is broken if you try linking two pieces of code that use different types for GLenum. I suppose this is technically up to the compiler and its chosen name mangling, but the end result is that this made it impossible to ship a C++ framework binary that worked on both 10.4 and 10.5. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
