Le 13 août 2012 à 19:54, John McCall <rjmcc...@apple.com> a écrit :
> On Aug 13, 2012, at 9:29 AM, Jean-Daniel Dupas wrote: >> Le 13 août 2012 à 17:56, Kyle Sluder <k...@ksluder.com> a écrit : >>> On Aug 13, 2012, at 8:42 AM, Ben <ben_cocoa_dev_l...@yahoo.co.uk> wrote: >>> >>>> I see in the documentation - and from a compiler error - that some classes >>>> are not compatible with weak references. >>>> >>>> What makes these classes incompatible? >>> >>> They have custom implementations of -retain and -release. >>> >>> When NextSTEP was first released, there was no refcounting, just +new and >>> +free. That's why NSObject (actually Object at the time) has only one ivar: >>> isa, a pointer to the object's class. >>> >>> Some time later -retain and -release came into being, but the storage for >>> refcount couldn't be added to Object because of the fragile base class >>> problem—all existing code expected sizeof(Object)==sizeof(id), so they >>> hardcoded offsets for accessing subclass ivars. >> >> I don't get it. retain/release has been introduced by NSObject. >> As all classed that use ref counting are based on NSObject and not Object, >> it was perfectly possible to declare 2 ivars in NSObject without breaking >> anything when it was first introduced. > > In the so-called "fragile" ABI, which is what you get on PPC, PPC64, and > i386, class layout is performed at compile time, and the machine code pattern > for accessing an ivar is the same as accessing a struct member: the compiler > knows that 'int count;' is at offset 32 (say), so it just adds 32 to the base > pointer value to find the address of the ivar. This is why all ivars have to > be declared in the main @interface when compiling for these platforms: it > would otherwise be impossible to do class layout for subclasses. Adding an > ivar to a class would change that layout, causing all code with class layouts > or ivar accesses compiled against the existing layout to stop working. > > There were releases made with NSObject having no ivars (except 'isa'). > Therefore adding new ivars would have broken binary compatibility with those > releases. Thanks for the details. I know what the fragile ABI, and the modern ABI are but where I don't agree is when Kyle says that it was not possible to add a refcount ivar when retain/release was introduced. As retain/release was already defined in the first OpenStep specification (http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Protocols/NSObject.html), it was perfectly possible at that time to choose to add a refcount ivar to the new NSObject class without breaking anything. I don't know the rational behind this choice, but it was probably to not force all classes to have an eventually useless ivar (constant NSString for instance don't need it). -- Jean-Daniel _______________________________________________ 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
