Re: @property problem
Re: @property problem
- Subject: Re: @property problem
- From: William Squires <email@hidden>
- Date: Sun, 17 Feb 2008 10:59:38 -0600
But it doesn't answer the question. Why even make the change in
the 64-bit runtime? This would seem to hide a source of bugs, by
taking the responsibility for providing storage away from the
programmer. Some storage is still necessary. And besides, in order to
take advantage of Leopard features like this one (whether on PPC or
Intel), you should still have to link against the 10.5 SDK, so it
would seem more reasonable to make the update to both the 32 and 64-
bit runtimes, but only in the 10.5 SDK. Then you could update the
10.5 SDK (to 10.5.1) to allow for this "syntactic sugar" under both
32- and 64-bit.
I mean, after all, all it means is that you're changing the
default size of an (Integer) register in the CPU chip, and updating
the OS to take advantage. How would this make implementing (or not
implementing) this change any harder or easier?
On Feb 16, 2008, at 6:03 PM, Jean-Daniel Dupas wrote:
Because changing the 32 bits runtime to support this kind of
feature would have break binary compatibility with previous
version, and previous applications.
This is the same for "zero-cost" exceptions that works with 64 bits
applications, but not with 32 bits applications.
And it is also the case for the fragile ivar problem that was solve
in the 64 bits runtime.
Le 16 févr. 08 à 23:35, William Squires a écrit :
Okay, but why the diff? Why should it matter whether you're using
32 or 64 bits? Storage is still storage, and it seems you'd still
need to provide that storage even under a 64-bit runtime.
On Feb 11, 2008, at 3:29 PM, Joshua Emmons wrote:
I've boiled the problem down to this snippet:
@interface MyWindow : NSWindow
{
}
@property(readwrite) BOOL capturing;
...
error: synthesized property 'capturing' must either be named the
same as a compatible ivar or must explicitly name an ivar
You haven't declared a compatible ivar named "capturing". You'd
need to do something like this:
@interface MyWindow : NSWindow
{
BOOL capturing; // <-- here!
}
@property(readwrite) BOOL capturing;
The line marked above declared an ivar with the same name and the
same type as your property declaration, so now synthesize will be
able to do its thing.
Obj-C *can* be smart enough to generate this ivar for you behind
the scenes, but only if you're using the 64bit runtime. If you
don't require 32bit compatibility, turn it off, and then you
don't have to worry about declaring these ivars for synthesize.
Cheers,
-Joshua Emmons
_______________________________________________
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:
40satx.rr.com
This email sent to email@hidden
_______________________________________________
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:
40shadowlab.org
This email sent to email@hidden
_______________________________________________
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