|Issue 969:||Enhancement Request: iOS 5 ARC compatibility|
|5 people starred this issue and may be notified of changes.||Back to list|
iOS 5 Beta 7 just released this week, and it is generally expected the iOS 5 GA is basically going to happen any time. iOS 5 introduced a major Objective-C shift, that being a change to the memory management approach. While on the surface this approach is syntactical, offering the benefits of greatly simplified and abbreviated code compared to present retain/release and dealloc requirements, under the hood, it offers great performance benefits and reduces the possibility of memory leaks. ZXing needs to be migrated, or else it will be unable to be used in ARC compatible projects.
Sep 2, 2011
This isn't going to happen soon (but I think we should leave the issue so we can point people at it). ARC is entirely compatible with non-ARC code on a .o by .o basis. If there are any header files that could be tweaked to make ARC happier, that's great, but they'd have to be done in a backwards compatible way. Most projects are not going to convert to ARC immediately (and perhaps not ever). Moreover, requiring ARC ties zxing to compiler and runtime versions and that's not good. (Heck, currently zxing doesn't compile correctly with optimizations for released llvm compilers even without ARC.) So we should gather patches for headers that ARC .o's need, but we shouldn't do anything that is not backwards compatible.
Labels: Type-Enhancement Module-iphone Priority-Low
Jan 15, 2012
I hope the developers reconsider, ARC is important, not for the old projects but for the new ones. A substantial amount of work is being developed with ARC (It saves at least a couple of days plugging memory leaks in simple projects, just imagine the benefits it gives to huge Objective C project), and it is not inconceivable for Apple to make ARC mandatory in the near future. Retro-fitting non-ARC codes is a pain, worse is going back to rewrite the code to a non ARC version.
Jan 16, 2012
Steven didn't say "no" -- it's that you need to provide a patch if you're quite interested in this.
Jan 16, 2012
My Apologies, I did get ZXing to work with an ARC project with very little change, I just removed some of the autorelease statements copied from sample codes (Scantest). There are some issues... setting up the dependencies and getting the headers to work is a pain but none of them are really related to the use of ARC in my project, seems to treat ZXingWidget compilation separately and it really doesn't matter if ZXingWidget is ARC compliant or not. ... It would be nice to have ZXingWidget fully ARC compliant but it is not necessary. Maybe for beginners ... and to avoid the redundant rework it will also be good to have an ARC sample code of ScanTest and Barcodes.
Jan 16, 2012
Right. ZXing can be used from either ARC or non-ARC code. At this point, converting the ZXing core to ARC would make it unusable to people working with gcc and/or older versions of Xcode. So converting ZXing to ARC would creating limitations and but incur no benefit. Unless there's a compelling reason, my vote is to wait. (Not to mention that as I recall the core widget code does not comply with the Cocoa naming conventions so conversion to ARC is going to be non-trivial.) I can see where it'd be nice to have example apps that demonstrate ARC but I don't relish the idea of trying maintain two versions of the same code. There is a converter-to-ARC function in Xcode. In theory that should work. If it has any trouble with the test code, we could look at simplifying that so that the converter worked without hit any snags. That way people that wanted an ARC example could simply convert the existing non-ARC example.
Mar 12, 2012
Also a won't-fix in my view based on smparkes's comments.
Mar 12, 2012
Agreed, at least for now.
|► Sign in to add a comment|