Re: Xcode 5 & Obj-C++
Re: Xcode 5 & Obj-C++
- Subject: Re: Xcode 5 & Obj-C++
- From: Eric Wing <email@hidden>
- Date: Thu, 30 Jan 2014 14:43:45 -0800
On 1/30/14, Jens Alfke <email@hidden> wrote:
>
> On Jan 30, 2014, at 4:32 AM, Jean-Daniel Dupas <email@hidden>
> 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 (email@hidden)
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:
This email sent to email@hidden