Fix "Bitmasking for introspection of Objective-C object pointers is strongly discouraged" warning in Xcode 5

[roustem]

.../JSONKit/JSONKit.m:2600:77: warning: bitmasking for introspection of Objective-C object pointers is strongly discouraged [-Wdeprecated-objc-pointer-introspection] BOOL workAroundMacOSXABIBreakingBug = (JK_EXPECT_F(((NSUInteger)object) & 0x1)) ? YES : NO;

.../JSONKit/JSONKit.m:199:53: note: expanded from macro 'JK_EXPECT_F'
# define JK_EXPECT_F(cond)               JK_EXPECTED(cond, 0U)

```
                                                ^
```

.../JSONKit/JSONKit.m:197:65: note: expanded from macro 'JK_EXPECTED'
# define JK_EXPECTED(cond, expect)       __builtin_expect((long)(cond), (expect))

[johnz2]

+1

[mikeabdullah]

We (@karelia) would appreciate this being fixed too

[jdberry]

+1

[mralexgray]

+1

Oh, btw, you can shut this up, like so...

#pragma clang diagnostic push #pragma clang diagnostic ignored "-Wdeprecated-objc-pointer-introspection" BOOL workAroundMacOSXABIBreakingBug = (JK_EXPECT_F(((NSUInteger)object) & 0x1)) ? YES : NO; #pragma clang diagnostic pop

[jslicari]

+1

[WeeTom]

+1

[vjacheslav-volodko]

+1

[odyth]

For iOS apps I just commented that line out and it hasnt had any negative impact on my app as far as i can tell. Been in production for about 6 months now.

[coveloper]

+1

[ramakula]

+1

[demodit]

+1

[mmcer]

@roustem ,what about (JK_EXPECT_F(((NSUInteger)object) % 2)) ?

[vchav73]

If you're using JSONKit I suggest you consider migrating to Apple's NSJSONSerialization. It does what JSONKit does, but according to the article below it's faster. Unlike JSONKit, it's also being maintained. The only downside I'm aware of is that it's only available in iOS 5+ / OS X 10.7+.

http://stackoverflow.com/questions/16218583/jsonkit-benchmarks

[abhibeckert]

@vchav73 it's also not entirely clear it's faster. That test you linked to only showed a slight performance difference and was run in the simulator, so complied for x86 instead of ARM.

There is also another comment that NSJSONSerialization is only fast on iOS 6, not 5. On 5 it was definitely too slow.

Since I'm decoding megabytes of JSON at a time, it's pretty important to me... when I get a chance I'll test it out and post an update here. Unless someone else beats me to it.

[jslicari]

In my experience NSJSONSerialization can be a bit buggy on iOS 5. I have definite cases of perfectly valid JSON that crap out on iOS 5 (produce a nil result) but work fine on iOS 6. So if your app is does not need to support iOS 5 or less I would say definitely migrate to NSJSONSerialization. Otherwise I would keep using JSONKit.

And if you really want to get rid of the JSONKit warning, I found that just putting these #pragma statements around the offending line does the trick:

pragma clang diagnostic push

pragma clang diagnostic ignored "-Wdeprecated-objc-pointer-introspection"

BOOL workAroundMacOSXABIBreakingBug = (JK_EXPECT_F(((NSUInteger)object) & 0x1)) ? YES : NO;

pragma clang diagnostic pop

[vchav73]

Thanks for the warnings about NSJSONSerialization on iOS 5.x. I ran some quick benchmarks (JSONKit vs NSJSONSerialization) on both an iPhone 3GS using iOS 5.1.1 and an iPad 2 using iOS 6.1.3 using the repo at this link: https://github.com/bontoJR/iOS-JSON-Performance

Seems, generally speaking, JSONKit is faster in iOS 5 while NSJSONSerialization is faster in iOS 6.

iPhone 3GS iOS 5.1.1:

iPad 2 iOS 6.1.3

[Bo98]

Yep, probably even more so in iOS 7.

[vchav73]

I'll add iOS 7 to the mix once it's released. Based on this (and the comment about NSJSONSerialization being buggy in 5.x) I'll be using NSJSONSerialization for iOS 6 and JSONKit for iOS 5 and earlier.

[abhibeckert]

Seems, generally speaking, JSONKit is faster in iOS 5 while NSJSONSerialization is faster in iOS 6.

Or JSONKit is more suited to the 3GS processor than the iPad 2 processor.

[Bo98]

I did the test a few months ago on the same device and got the same result.

[odyth]

I did some tests of my own and NSJSONSerialization is marginally faster on serialization and about 1.5x faster on deserialization, however you loose the ability to serialize custom objects. JSONKit lets you specify a block call back for custom classes NSJSONSerialization doesn't have this. I will have to loop through all the custom objects changing them into array's or dictionaries prior to handing it off to NSJSONSerialization, this will make it so JSONKit is clearly faster at serialization. Also since JSONKIt is open source I had modified it to omit NSNull from the dictionaries it returns, which since I want this feature requires me to strip NSNull's either at runtime or right after deserializing which will reduce the 1.5x speed advantage of NSJSONSerialization. JSONKit is more flexible then NSJSONSerialization its a shame the project has been abandoned.

[abhibeckert]

JSONKit is more flexible then NSJSONSerialization its a shame the project has been abandoned.

I wonder if JSONKit could be changed/forked as a wrapper around NSJSONSerialization. Just switch to using Apple's library under the hood, but keep the flexibility.

For example, omitting NSNull and custom objects could be done by using dispatch_apply() recursively after decoding with NSJSONSerialization.

[odyth]

@abhibeckert it wouldn't be as fast as just JSONKIt if it used NSJSONSerialization under the hood. also how would you use dispatch_apply to edit a mutable collection? wouldn't it crash as you were iterating and editing?

[abhibeckert]

@odyth you just create a new collection. That's a pretty inexpensive thing to do, in terms of performance. The actual contents of the dispatch_apply() will be much slower.

[jdberry]

Due to the fact that this project is apparently abandoned, I've now given up on JSONKit in favor of NSJSONSerialization.

[odyth]

What are you doing for custom object serialization?

On Wednesday, September 11, 2013, James Berry wrote:

Due to the fact that this project is apparently abandoned, I've now given up on JSONKit in favor of NSJSONSerialization.

— Reply to this email directly or view it on GitHubhttps://github.com/johnezang/JSONKit/issues/133#issuecomment-24289840 .

-justin

[benliong]

@abhibeckert probably the only reason to fork JSONKit is so that people with deployed codes using JSONKit do not need to change their code.

[innocarpe]

+1 :)

[alvinchan]

+1

[BryanOne]

+1

[toddfreese]

+1 Anyone have a fix for this?

[abhibeckert]

I wish people would stop hitting +1, as everyone who's subscribed to this issue gets an email notification each time.

@toddfreese the solutions are:

• switch to Apple's official JSON API which is faster and guaranteed to continue working for the foreseeable future.
• ignore the compiler warning, which doesn't actually seem to cause any issues (I wouldn't risk compiling your app in 64 bit mode without testing thoroughly on an iPhone 5S however, since it may be broken).

[akinLiu]

+1

[erloncabral]

+1

[Pandan]

+1

[jcbertin]

Have a look at #158. It will fix tagged pointers even for iOS 8 or MacOS 10.10.