• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: @property problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: @property problem


  • Subject: Re: @property problem
  • From: Bill Bumgarner <email@hidden>
  • Date: Sun, 17 Feb 2008 12:17:51 -0800

On Feb 17, 2008, at 12:03 PM, Sherm Pendley wrote:
Why would the parent's size be hard-coded? You can get the size of the parent at run time, by dereferencing a couple of levels into isa. All the compiler would have to do is emit code that walks down isa to get the parent's size, and add it to self to establish a base address. The only hard-coded offsets would then be relative to that base, for the current class' own ivars.

Changing the size of the parent class wouldn't break such a scheme, so far as ordinary usage goes. People playing games with sizeof() or @defs deserve whatever breakage they get. :-)

Doesn't the current (I refuse to call it "legacy" quite yet...) 32- bit compiler emit code like that when ivars are accessed?

To dive a little deeper, consider the instance variables for NSView, including inherited ivars. Well, a subset, really:


@interface NSObject <NSObject> {
    Class	isa;
}

@interface NSResponder : NSObject <NSCoding>
{
    id _nextResponder;
}

@interface NSView : NSResponder
{
    NSRect              _frame;
    NSRect              _bounds;
    id                  _superview;
    id			_subviews;
    NSWindow            *_window;
}

Within the legacy runtime ;), the memory for NSView looks just like a C struct with this layout:

struct NSViewLikeStruct {
    Class	isa;
    id _nextResponder;
    NSRect              _frame;
    NSRect              _bounds;
    id                  _superview;
    id			_subviews;
    NSWindow            *_window;
};

So, in the implementation of an NSView, an access to an instance variable -- say _subviews -- is compiled down to something equivalent to:

((struct NSViewLikeStruct *) aView)->_subviews

Now, if an instance variable is added to NSObject or NSResponder and the subclasses are not compiled, the above code will have the wrong offset.

This is fragile, but allows instances to be allocated as a single chunk of memory while also reducing the amount of metadata and/or indirection required to get at any given instance variable's slot.

To fix the issue, it has to be done partially at runtime and requires a different layout for the instances...

b.bum

_______________________________________________

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


References: 
 >@property problem (From: Randall Meadows <email@hidden>)
 >Re: @property problem (From: Joshua Emmons <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jean-Daniel Dupas <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Jim Correia <email@hidden>)
 >Re: @property problem (From: William Squires <email@hidden>)
 >Re: @property problem (From: Bill Bumgarner <email@hidden>)
 >Re: @property problem (From: "Sherm Pendley" <email@hidden>)

  • Prev by Date: NSPreferencePane IB Problem
  • Next by Date: Re: Icons in Dockmenu
  • Previous by thread: Re: @property problem
  • Next by thread: Re: @property problem
  • Index(es):
    • Date
    • Thread