NSNumber is completely broken
NSNumber is completely broken
- Subject: NSNumber is completely broken
- From: Todd Blanchard <email@hidden>
- Date: Wed, 25 May 2005 03:34:16 -0700
| I'm working on bridging Cocoa to another language and have found that NSNumber is totally broken. Does nobody bother to test anything anymore?
These are the objective C types recorded for various C types
Bool: c Char: i Unsigned Char: i Short: i Unsigned Short: i Int: i Unsigned Int: i Long: i Unsigned Long: i Float: f Double: d
But it should be: BOOL: c char: c unsigned char: C short: s unsigned short: S int: i unsigned int: I long: l unsigned long: L float: f double: d (mini-rant - why bother to have numberWithBool if the value is indistinguishable from char once the NSNumber is created?) I got it using this little program:
id n = nil; #define T(type) n=[NSNumber numberWith ## type : 0]; printf("%s:\t\t\t\t%s\n", #type , [n objCType]); #define U(type) n=[NSNumber numberWithUnsigned ## type : 0]; printf("Unsigned %s:\t%s\n", #type , [n objCType]); #define C(type) printf("%s: %s\n", #type ,@encode(type));
T(Bool) T(Char) U(Char) T(Short) U(Short) T(Int) U(Int) T(Long) U(Long) T(Float) T(Double)
C(BOOL) C(char) C(unsigned char) C(short) C(unsigned short) C(int) C(unsigned int) C(long) C(unsigned long) C(float) C(double)
Suggestions on workarounds? My two initial thoughts are to replace all the initialization methods on NSNumber using a category or to subclass it and pose. Comments on pros and cons of each would be welcome. If I pose, I suppose I could add an extra flag to mark whether its a bool or not. What else?
Filed Bug: 4129891
-Todd Blanchard |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden