• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSNumber pointerValue
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSNumber pointerValue


  • Subject: Re: NSNumber pointerValue
  • From: Dietmar Planitzer <email@hidden>
  • Date: Thu, 20 Nov 2003 23:06:58 +0100

On Nov 20, 2003, at 7:56 AM, Bjvrn Carlstrvm wrote:


2003-11-19 kl. 23.02 skrev Dietmar Planitzer:


On Nov 19, 2003, at 8:45 PM, Bjvrn Carlstrvm wrote:

Just a guess, but it may be the case that NSNumber gets confused because at first it gets created as an integer container, then serialized when copied to the pasteboard and then after de-serialization you ask it for a pointer value. NSNumber and NSValue internally store the data type of their value.

Do you know how NSNumber and NSValue store values internally? Then you must know the answer to this! My original question was why would NSValue return a different result after being put on the pasteboard? Different storing might explain it. Still inconsistency seems more like a bug then a feature.

At least in the Rhapsody days, NSNumber was a class cluster with a dedicated subclass for each data type. So, for example [NSNumber numberWithInt: 10] would return an instance of the NSIntNumber subclass. That way the data type was implicitly encoded as part of the subclass. NSValue on the other hand stored the ObjC data type encoding string explicitly. Today the situation may be slightly different because NSNumber is now toll-free bridged with CFs CFNumber. Anyway, it may indeed be the case that there is a bug whereby the -pointerValue method may not correctly do its job with some kinds of numbers.


In any case, you should never cast a pointer to an int. This works on the current hardware and OS but is likely going to fail as soon as OS X gets support for 64bit address spaces.

I know, it's a workarround because of the above problem. I would love to use pointerValue and be safe in the future. Can you suggest a more robust workarround? I'm a little relluctant to guess what NSNumber will return in a 64 bit future, with the inconsistences above...

In this case a more robust approach to store a weak pointer would be to use NSData. For example (untested code):

@implementation NSData(ABC)

+ (NSData *)dataWithPointer: (void *)ptr
{
void ** tmp;

*tmp = ptr;
return [NSData dataWithBytes: &tmp length: sizeof(void *)];
}

- (void *)pointerValue
{
return *((void **) [self bytes]);
}

@end


Regards,

Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: NSNumber pointerValue (From: Wade Tregaskis <email@hidden>)
 >Re: NSNumber pointerValue (From: Björn Carlström <email@hidden>)
 >Re: NSNumber pointerValue (From: Glenn Andreas <email@hidden>)
 >Re: NSNumber pointerValue (From: Björn Carlström <email@hidden>)
 >Re: NSNumber pointerValue (From: Alastair Houghton <email@hidden>)
 >Re: NSNumber pointerValue (From: Björn Carlström <email@hidden>)
 >Re: NSNumber pointerValue (From: Dietmar Planitzer <email@hidden>)
 >Re: NSNumber pointerValue (From: Björn Carlström <email@hidden>)

  • Prev by Date: Re: Mailing list: General options
  • Next by Date: Re: Dynamically Generating GUI forms from an XML file?
  • Previous by thread: Re: NSNumber pointerValue
  • Next by thread: Re: NSNumber pointerValue
  • Index(es):
    • Date
    • Thread