Re: Size of -[NSEvent type]
Re: Size of -[NSEvent type]
- Subject: Re: Size of -[NSEvent type]
- From: Ali Ozer <email@hidden>
- Date: Fri, 30 Nov 2007 10:28:41 -0800
The transition documentation suggested to me that the decision
whether to
convert to NSInteger and NSUInteger was somewhat more
discriminating, and
that some ints and unsigned ints weren't changed
No, the change was pretty global. The only types that did not move
were those where the underlying C type or the size are significant in
the API or functionality; for instance, initWithInt: vs
initWithInteger: in NSNumber, or intValue vs integerValue in NSCell.
Similarly, with floats, all graphical floats moved to CGFloat, and the
only remaining occurrences of float are those where the underlying C
type is important, or the value is not graphical (such as volume
method in NSSound).
In general, moving forward, all Cocoa apps should just use NSInteger
or NSUInteger for their integral types, and APIs. One scenario where
it's interesting to consider a smaller type is in fields of widely
allocated objects, as a way to save on storage. However the accessors
for those properties would still likely be in terms of NSInteger or
NSUInteger.
I asked because I'm writing an Objective-C wrapper framework for
Quartz
event taps. I'm struggling to decide what conventions I should
follow with
regard to typing the values I'm wrapping, such as CGEventType.
In this one case using uint64 might be reasonable, and would
accommodate some possible future scenarios. Say we added more event
types that we had to support under 32-bit, requiring us to perhaps add
some new APIs representing event masks as 64-bit quantities. On the
other hand we don't have any case of this in Leopard, so I think
NSUInteger is just fine, and might be preferable if you wish the keep
the API a little more consistent.
Ali
On Nov 30, 2007, at 09:36 , Bill Cheeseman wrote:
on 2007-11-30 11:11 AM, Ali Ozer at email@hidden wrote:
All int-sized types in Cocoa moved to NSInteger or NSUInteger under
64-
bit, so what happened to NSEventType is consistent with everything
else. This is true even if the type in question isn't likely to hold
a value greater than 2 or 4 billion in the foreseeable future.
As far as masks, the 32-bit mask has been getting close to full, so
we
even considered moving to a 64-bit mask under 32-bit. However, since
this would be a binary incompatible change for NSEvent and likely
require new APIs to do right, we instead allow for a 64-bit mask
under
64-bit only. Clearly the top 32-bits can't be except in 64-bit
scenarios, and we're not making any use of it at this point.
Thanks for the info.
The transition documentation suggested to me that the decision
whether to
convert to NSInteger and NSUInteger was somewhat more
discriminating, and
that some ints and unsigned ints weren't changed. I wondered why
NSEventType
wasn't one of those special cases, since it seems unlikely that
we'll see
more than 2 billion different event types even in the unforeseeable
future.
I asked because I'm writing an Objective-C wrapper framework for
Quartz
event taps. I'm struggling to decide what conventions I should
follow with
regard to typing the values I'm wrapping, such as CGEventType. Being
focused
on Cocoa, I prefer to follow NSEvent's conventions as closely as
possible.
But, to my surprise, there are some declarations in CGEvent.h (namely,
CGEventFlags and CGEventMask) that are uint64_t and therefore yield
64-bit
variables whether you're running as 32-bit or 64-bit -- yet their
NSEvent
counterparts (e.g., NSEventMask) can be 32-bit running as 32-bit.
I guess you're telling me that the top 32-bits aren't likely to be
used in a
32-bit environment until NSEvent's equivalent is re-typed as
uint64_t or
long long. So I'm safe for the time being using the NSEvent
conventions. (As
long as I'm right in thinking that CGEvent and NSEvent are closely
linked. I
assume they are, since they both seem to rely in one way or another on
IOLLEvent.h in the IOKit framework.)
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
_______________________________________________
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