Re: Help with NSPointerArray and NSMapTable

Christiaan Hofman <[email protected]>
Newsgroups gmane.comp.macosx.devel
Message-ID <[email protected]>
On Sep 23, 2009, at 10:42, Jonathan Dann wrote:

> On 23 Sep 2009, at 01:27, Christiaan Hofman wrote:
>
>>
>> On Sep 23, 2009, at 1:25, Jonathan Dann wrote:
>>
>>>
>>> On 23 Sep 2009, at 01:10, Christiaan Hofman wrote:
>>>
>>> [snip]
>>>
>>>> Right, that's basically what I proposed as well. So I also need  
>>>> to use this for simple types like CGFloat that are not pointer- 
>>>> sized?
>>>
>>> Yep.
>>>
>>> [snip]
>>>
>>>> Nice samples, that surely helps. Thanks. I just find it confusing  
>>>> that for NSInteger it works differently. Though I guess I could  
>>>> do the same.
>>>
>>> No problem. When you're doing this, you're not casting an integer  
>>> to a pointer, so AFAICT the caveats in the 64-bit docs don't apply  
>>> here.
>>>
>>> Jonathan
>>
>> As I understand it now, you do cast an integer to a pointer when  
>> you use NSPointerFunctionsIntegerPersonality. So these caveats do  
>> apply.
>
> Yeah but you don't have to use the integer personality with integers  
> or floats. If you have a struct with a single int then you can case  
> between the struct and an int without loss of precision.
> I'm pretty sure that's what we're doing here. See:
>

But would you have to use the intermediate struct? Can't I just use  
e.g. a CGFloat (passed in by address) directly using  
NSPointerFunctionsStructPersonality? As I understand it this option  
does not really care about the exact data type, only a blob of memory  
of a certain size.

But I was (also)  talking about directly adding NSInteger with  
NSPointerFunctionsIntegerPersonality.

Christiaan

> http://www.algorithm.com.au/downloads/talks/objective-c-internals/objective-c-internals.pdf
>
>> Christiaan
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.