PDA

View Full Version : Is there any way to give Apple feedback on their APIs?




foidulus
Sep 19, 2010, 09:08 AM
I just have a little niggling complaint, namely that it isn't possible to wrap (u)int(32/64)_t objects into NSNumber objects(easily, I came up with a solution but its not pretty and not really cross platform).

It would be wonderful if we could pass around NSNumber objects and KNOW their size regardless of the platform we are on.

Is there any way I could contact Apple and ask for something like this? Has anyone ever had any luck doing so?



kpua
Sep 19, 2010, 09:40 AM
bugreport.apple.com is probably one of the easiest ways to communicate directly with Apple's developers. Try filing an enhancement request.

jared_kipe
Sep 19, 2010, 09:59 AM
Why not subclass NSNumber or make a category on it. Or make your own class and pass that object.

chown33
Sep 19, 2010, 01:52 PM
It would be wonderful if we could pass around NSNumber objects and KNOW their size regardless of the platform we are on.
This doesn't seem difficult at all.

Call -objCType on the NSNumber, and dereference the returned char*, decoding it according to:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html%23//apple_ref/doc/uid/TP40008048-CH100-SW1

You could probably put the whole decoding procedure in a single function like:
extern size_t sizeOfNumber(NSNumber*);
Or maybe add it as a category of NSNumber. Either way, make sure you handle NSDecimalNumber properly (read its class reference doc).

If you want further suggestions, post the code for your solution, and examples of its use in real-life contexts. My first thought was -objCType, which seems to easily solve the problem stated, so maybe something about the difficulty isn't clear from your description, which would be more apparent by seeing code.

gnasher729
Sep 19, 2010, 05:03 PM
I just have a little niggling complaint, namely that it isn't possible to wrap (u)int(32/64)_t objects into NSNumber objects(easily, I came up with a solution but its not pretty and not really cross platform).

It would be wonderful if we could pass around NSNumber objects and KNOW their size regardless of the platform we are on.

Is there any way I could contact Apple and ask for something like this? Has anyone ever had any luck doing so?

+ numberWithLongLong:(long long)value

will accept any signed integer type and return an NSNumber object with the given value.

+ numberWithUnsignedLongLong:(unsigned long long)value

will accept any unsigned integer type and return an NSNumber object with the given value.

Completely portable.

foidulus
Sep 19, 2010, 06:32 PM
+ numberWithLongLong:(long long)value

will accept any signed integer type and return an NSNumber object with the given value.

+ numberWithUnsignedLongLong:(unsigned long long)value

will accept any unsigned integer type and return an NSNumber object with the given value.

Completely portable.

Yep, my mistake. I assumed that unsigned long longs were like ints, ie they were different sizes on different architectures. But it turns out that they are not(printed out a sizeof(long long) on both i386 and x864_64), mea culpa.

gnasher729
Sep 20, 2010, 03:43 AM
Yep, my mistake. I assumed that unsigned long longs were like ints, ie they were different sizes on different architectures. But it turns out that they are not(printed out a sizeof(long long) on both i386 and x864_64), mea culpa.

Well, they are not guaranteed to be always the same size; they might become 128 bits in ten years time, but the point is that they are _always_ big enough to hold a uint32_t or uint64_t. "long long" is guaranteed to be at least 64 bits. "long" is guaranteed to be at least 32 bits, so you can portably use it to store an int32_t. Apple guarantees that it is big enough to hold an NSInteger.

ShortCutMan
Sep 20, 2010, 07:20 AM
Yep, my mistake. I assumed that unsigned long longs were like ints, ie they were different sizes on different architectures. But it turns out that they are not(printed out a sizeof(long long) on both i386 and x864_64), mea culpa.

I don't know how it is in the C/Obj-C spec, but surely it can't be too much different than the C++ spec. But anyway, from what I know, the definition of the size of integers (and their varieties) are up to the compiler and are merely related to whatever size they choose for an int. Might be worth looking into further if it is highly related to the work you're doing?