Size of -[NSEvent type]

  • In Leopard, the -[NSEvent type] method returns a value of type NSEventType.
    In the NSEvent.h header, this is declared as NSUInteger, meaning that it
    will occupy 32 bits in a 32-bit app or 64 bits in a 64-bit app.

    Why is this?

    I was under the impression that an event type is always 32 bits.
    Consistently with my understanding, the Core Graphics API, in
    CGEventTypes.h, defines CGEventType as uint32-t.

    I get even more confused when I look at the declarations of event masks. In
    NSEvent.h, the event masks aren't assigned a type, but NSAnyEventMask is
    declared to be NSUIntegerMax. In Core Graphics, CGEventMask is declared as
    uint64_t.

    What am I misunderstanding?

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • 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.

    Ali

    On Nov 30, 2007, at 04:29 , Bill Cheeseman wrote:

    > In Leopard, the -[NSEvent type] method returns a value of type
    > NSEventType.
    > In the NSEvent.h header, this is declared as NSUInteger, meaning
    > that it
    > will occupy 32 bits in a 32-bit app or 64 bits in a 64-bit app.
    >
    > Why is this?
    >
    > I was under the impression that an event type is always 32 bits.
    > Consistently with my understanding, the Core Graphics API, in
    > CGEventTypes.h, defines CGEventType as uint32-t.
    >
    > I get even more confused when I look at the declarations of event
    > masks. In
    > NSEvent.h, the event masks aren't assigned a type, but
    > NSAnyEventMask is
    > declared to be NSUIntegerMax. In Core Graphics, CGEventMask is
    > declared as
    > uint64_t.
    >
    > What am I misunderstanding?
    >
    > --
    >
    > Bill Cheeseman - <bill...>
    > Quechee Software, Quechee, Vermont, USA
    > www.quecheesoftware.com
    >
    > PreFab Software - www.prefabsoftware.com
    >
    >
  • on 2007-11-30 11:11 AM, Ali Ozer at <aozer...> 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 - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • > 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 <aozer...> 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 - <bill...>
    > Quechee Software, Quechee, Vermont, USA
    > www.quecheesoftware.com
    >
    > PreFab Software - www.prefabsoftware.com
    >
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today