Re: @property problem
Re: @property problem
- Subject: Re: @property problem
- From: "Sherm Pendley" <email@hidden>
- Date: Sun, 17 Feb 2008 15:03:35 -0500
On Feb 17, 2008 1:03 PM, Bill Bumgarner <email@hidden> wrote:
In the legacy -- 32 bit -- runtime, each subclass effectively tacks
> its instance variables onto the end of the superclass's instance
> variables as if it were all one big extensible C structure. If the
Okay, I can see how the basic assumption of one big continuous block of
memory might be limiting.
But, having said that... :-)
> superclass adds an ivar, the offset of the ivars in said structure are
> thus incorrect and, unless you recompile, subclasses will read/write
> from the wrong spot in memory and *boom*.
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?
sherm--
_______________________________________________
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