Migrating to ARC

[benuri]

Why not migrating iMedia to ARC?

[mikeabdullah]

We still support 32bit apps.

[benuri]

I see. So is it possible to add an optional support via preprocessor macros like this?

[mikeabdullah]

Perhaps a better question from me is "why do you want this?". iMedia builds a framework which should be perfectly compatible with an ARC app. If you're seeing a problem with this, that's a bug I'd like to fix.

[benuri]

I want this because I believe that ARC manages memory better than humans, and specifically better than I do.
(I have made some modifications in iMedia).

I want to be able to compile iMedia with ARC and see if it has better memory performance than with manual memory management (and use it if does work better).

[mikeabdullah]

The only way ARC has to use less memory with any significance than manual memory management is if it fixes a leak. And if ARC can do that, pretty much by definition, the static analyzer can too.

[benuri]

Not exactly, because ARC has some limitations on the code that helps it to manage memory better than what the static analyzer can detect. Otherwise the syntax could be exactly the same (especially without __bridge, weak and strong).

[mikeabdullah]

The __bridge etc. syntax exists so you can tell the compiler what you actually want to happen. Without that, it can know that you've done something wrong, but not be sure what you actually intended.

The only possible memory usage improvement ARC brings is from its autorelease implementation having the potential to destroy some objects a little earlier.

But quite frankly I have no interest in trying to convert and maintain such a large codebase dual-mode (or arguably even triple-mode as we technically support garbage collection still too). If you want to put in the legwork for this, be my guest and we'll see if others are happy with it. But it's a lot of effort for very little gain.