Re: NSUInteger question
Re: NSUInteger question
- Subject: Re: NSUInteger question
- From: "Michael Ash" <email@hidden>
- Date: Wed, 9 Apr 2008 15:44:53 -0400
On Wed, Apr 9, 2008 at 1:43 PM, Corbin Dunn <email@hidden> wrote:
>
> On Apr 9, 2008, at 9:39 AM, Michael Ash wrote:
>
> > On Wed, Apr 9, 2008 at 12:30 PM, Corbin Dunn <email@hidden> wrote:
> >
> > >
> > > On Apr 8, 2008, at 5:30 PM, Timothy Reaves wrote:
> > >
> > >
> > > > What advantage does NSUinteger have over uint32? I realize that
> > > >
> > > on a 64 bit machine, it would be a uint64.
> > >
> > > >
> > > >
> > >
> > > I think everyone is missing the point. The advantage is not "None".
> > >
> > > Chris Parker already gave the first good advantage. The second is this:
> Use
> > > NSInteger/NSUInteger everywhere in your app. Recompile it for 64-bit and
> you
> > > instantly have a fully 64-bit version with very little work. That's a
> huge
> > > advantage.
> > >
> >
> > But the same effect could be had simply by using "long" and "unsigned
> > long".
> >
>
> No, the same effect could not have been done, for one of the reasons you
> mention below.
Except that effect is basically only useful for Apple, not for third
parties, and I'm speaking from the perspective of a third party.
Preserving exact method signatures is great when you need binary
compatibility. Generally we don't need to preserve them, though.
Simply having a binary compatible method signature is enough;
everything works just fine on 32-bit if you declare long but the
caller thinks that it's int.
The one exception to this is passing pointer arguments around, where
the compiler will generate a warning. This is rare, though; Cocoa
doesn't have a lot of places which take NSInteger *. Otherwise, using
long and unsigned long is essentially equivalent to using NSInteger
and NSUInteger. Apple even lets us define those two types to only use
long.
> > IMO it's dangerous to talk about a 64-bit conversion in this manner.
>
> I disagree. It eases transition for apps that use the NSInteger type.
> Please read our release notes on the subject:
>
> http://developer.apple.com/releasenotes/Cocoa/Foundation.html#64Bit
>
> and the documentation:
>
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/Cocoa64BitGuide/Introduction/chapter_1_section_1.html
I have read both, I simply don't agree with the recommendation to use
NSInteger everywhere.
> > Much like any other architecture change, there are a lot of different
> > effects and blindly using "safe" types is not guaranteed to make your
> > app work after a recompile.
>
> Yes; there are many cases where blindly using NSInteger/NSUInteger can get
> you unexpected results. But, we document the typical pitfalls, and they are
> easy to avoid. Certain apps (like TextEdit) can simply be recompiled.
Aside from a couple of places where it uses deprecated APIs, the 10.4
version of TextEdit can *also* simply be recompiled. I didn't test it
thoroughly but it appeared to work just fine when compiled as x86_64.
(There is one bug in the scripting system due to the change, revealed
by a warning. There may be others.)
> > Likewise an application which uses
> > non-NSInteger types may be written to Just Work when recompiled as
> > 64-bit.
>
> That is true too. You can easily recompile an app that uses int/float and
> still having it do most of its computations with 32-bit values, or use
> appropriate types where applicable. But that isn't a full 64-bit app unless
> you convert all uses of int to a larger type. You wouldn't write this on
> 32-bit:
>
> for (short i = 0; i < ..; i++)
>
> And similarly, you shouldn't write this on 64-bit:
>
> for (int i = 0; i < ..; i++)
I find this whole line of reasoning a bit difficult to follow. The
essence of 32/64 bitness in the context we're discussing is pointer
size, not integer size. Indeed, half of Apple's supported 64-bit
architectures also support native 64-bit integer computation when in
32-bit mode. I would think that being a "full 64-bit app" would be
related to being able to deal with data that goes beyond the limit of
the 32-bit address space, not the sizes of the integers you use in
loops. And while the two concepts are related, they are only loosely
so. There are plenty of cases where using a 32-bit quantity in 64-bit
land will always be sufficient, and where using a 64-bit quantity in
32-bit land is always necessary.
I also think it's dangerous to talk about these types as though they
solve everything when they don't, even if they do help.
> If you are using any Cocoa API's you should be using NSInteger/NSUInteger,
> and not doing so would require much more work.
What primitive types you use ought to be unrelated to what APIs you
use. After all, the need to be 64-bit clean exists whether you use
Cocoa or not.
> The question was "what advantage is there for using NSInteger/NSUInteger".
> The answer is 64-bit transition of your Cocoa apps.
It's certainly helpful, it's just neither necessary nor sufficient.
Mike
_______________________________________________
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