ARC Compatibility about novocaine HOT 7 OPEN

Although I should mention, it just takes a few modifications to get it to compile. Perhaps a separate branch people can fork, if they're working with ARC? Not sure how to proceed with this, all suggestions welcome.

from novocaine.

FWIW I ended up flagging Novocaine's files as no ARC and then simply factored my calls so that any allocations took place outside the blocks (so the blocks call a routine in my ARC context).

from novocaine.

Just to clarify, you don't have to worry about allocations in your client blocks being somehow "non-ARC" just because Novocaine is compiled with ARC disabled. ARC will still track whatever your block is doing, regardless of where it's called from, because the ARC guards are inserted into the block at compile time. Whether the block invoker is ARC or non-ARC doesn't affect anything*, all that matters are the compile settings of the file where the block is defined.

(*Except, in some cases, the autoreleased return value optimization; but that's a matter of performance not correctness, and it only applies when the block returns a retainable type.)

from novocaine.

One way to handle ARC compatibility, if the differences are very slight, would be to use preprocessor #ifs to check for ARC mode and make it compile in both modes.

from novocaine.

Go for it! I don't have any ARC projects right now, so I won't be doing this for awhile, but would love it if you tested this out.

On Apr 24, 2012, at 6:02 AM, Porgery wrote:

One way to handle ARC compatibility, if the differences are very slight, would be to use preprocessor #ifs to check for ARC mode and make it compile in both modes.

---

Reply to this email directly or view it on GitHub:
#4 (comment)

from novocaine.

I'm working on making Novocaine ARC-compatible and cleaning up the property/ivar structure to follow more modern best-practice conventions (no ivars without a good reason, auto-synthesized properties, correct atomicity and retention, sensible public/private access, etc). In my opinion it is beyond reasonable at this point to mandate that users have a version of XCode modern enough to support these things (XCode 4.4+).

Nearly all new projects I've come across these days use ARC, and for non-ARC projects, ARC can be enabled for compilation on a per-file basis for at least iOS 4.3+, which is also beyond reasonable at this point, especially with iOS 7 on the way. It's a similar case for OSX.

If you think there's a need to support older LLVM, I can add a few preprocessor definitions to check the compiler version and synthesize properties if it's an older version.

from novocaine.

I've created a pull request which makes the project compilable on ARC-enabled targets and keeps the code working for non ARC-projects. However there are still lots of "assign" properties, which may lead to dangling pointers and thus runtime errors.

from novocaine.