1

I am working on an iPhone app which does some video processing, I had to include to classes that are not ARC compliant ( dealloc , releasing stuff ). So I manually went and made them arc compliant. Later on I discovered the compiler flag for any class that can make it non ARC in an ARC project -fno-objc-arc.

My question is, if I do flag those classes with the compiler flag, what are the reprecussions of this? performance hit? is it a good idea? my app iOS 5.0 and up. I couldn't find any resources that talk about pros and cons of doing this.

Shoe
  • 74,840
  • 36
  • 166
  • 272
Huang
  • 1,355
  • 2
  • 11
  • 28
  • [Here is a pretty good description of ARC][1]; Its advantages and disadvantages. [1]: http://stackoverflow.com/questions/7888568/what-are-the-advantages-and-disadvantages-of-using-arc – Ares Jan 26 '13 at 20:06
  • 1
    Why don't you convert non-ARC files to ARC files? – P.J Jan 26 '13 at 20:07

2 Answers2

3

You ask:

If I do flag those classes with the compiler flag, what are the repercussions of this?

The only thing I believe you need to worry about is to make sure that the non-ARC library follows Cocoa naming conventions associated with memory management (e.g. only return objects with +1 retainCount if the name begins with alloc, new, copy, or mutableCopy). Otherwise your ARC won't be able properly manage the resulting object. Most well written classes will conform to this pattern, so you should be perfectly ok using the fno-objc-arc flag, but it depends entirely upon the class in question.

[Is there a] performance hit?

There are no practical performance issues.

[Is] it a good idea?

All things being equal, I generally like to convert the code to ARC. A couple of situations where I might refrain from converting:

  • It is a library for which there is active development, and if I create my own personal ARC fork, I'll lose out on the future revisions of the library.

  • The library is incredibly complex and/or has constructs that are not easily converted to ARC.

Bottom line, if I can convert to ARC, I will. Usually in this process, I'll do the necessary testing to make sure I'm comfortable with the library, that there are no leaks, etc., so it's a productive (if annoying) process to go through. We're all responsible for the code we include in our projects and I don't think one should ever integrate code without going through some due diligence that is a natural by-product of an ARC-conversion and testing process.

If I convert to ARC, I offer to contribute the conversion back to the original author (e.g. via a GitHub "pull request" or whatever mechanism the author is open to) so it can be integrated into the code base.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
0

At first glance, there are no performance issues with using or disusing ARC. ARC is basically normal reference counting, it's just not the programmer who inserts the release calls, but the compiler.