2

This might be a silly question, but I just wanted to know. I want my code to detect if ARC is enabled, programmatically. How do I do that? Is there is any flag that I could check? Actually the problem is that, I have written an open-source library. I have used release and retain in it. if some one else uses my library files using ARC enabled, I dont want them to get any errors. how do I achieve this? or is there any possible ways I can provide any tools to compile my library before using it?

dhilipsiva
  • 3,688
  • 1
  • 24
  • 35
  • Xcode and ARC will not allow you to use retain og release, and give you errors. – Martol1ni May 22 '12 at 10:59
  • @DhilipSiva Please, Do see that you check all the grammatical mistakes, alignment before posting a question. Do read http://stackoverflow.com/faq#etiquette before posting. – Beginner May 22 '12 at 12:24

3 Answers3

19
#if !__has_feature(objc_arc)
    //Do manual memory management...
#else
    //Usually do nothing...
#endif

This is of course a compile-time check, you cannot check for ARC at runtime.

An alternative would be to set the -fno-objc-arc compiler flag for your files that use manual memory management in a project that otherwise uses ARC.

Whether you want to bother with this at all or just use ARC everywhere depends on how backward-compatible you want/need to be. Code that supports both ARC and MRC can get quite hard to read and maintain.

omz
  • 53,243
  • 5
  • 129
  • 141
2

You don't detect it programmatically, it operates based on translations. That is, it is not like Garbage Collection -- which is process-wide, required all linked libraries to support (and implement it correctly in that mode). You can have some files compiled with ARC, and some without.

However, you can detect it at compilation.

As far as the distribution of your library: I would not bother with a translation based system, where ref count ops are conditionally enabled. I would (personally) just support one model (MRC in your case, until you choose to migrate it to ARC), then expect people to link to the library, or if they compile it in a target they configure, to disable ARC. Conditionally enabling/disabling code based on the presence of a feature is asking for tough bugs, particularly when it's likely to affect 9% of your library's lines of code.

Community
  • 1
  • 1
justin
  • 104,054
  • 14
  • 179
  • 226
  • Agreed. People can either disable ARC themselves for the source files, or you just distribute the .a files which will work fine. I guess you could still use a #error at compile time to warn the user they need to disable ARC for your source files. – Mike Weller May 22 '12 at 11:20
  • @MikeWeller It's also easy to distribute as an xcodeproj with sources (when that is an option). An explicit `#error` at a high level `#include` is a nice touch, but that problem would manifest soon enough in this case (because it is MRC). If it *required* ARC OTOH, a high level `#error` should be considered a requirement (in the event the static analyzer's warnings weren't enough of a hint, or of the client never used the facilty). – justin May 22 '12 at 11:35
1

NO, you can't, Xcode would not compile in ARC projects if your source uses retain-release

Teofilo Israel Vizcaino Rodrig
  • 1,480
  • 1
  • 13
  • 25