No description provided.
Support compiling with ARC under Clang using ifdefs.
Thank you very much Alex, but I prefer compiler flag -fobjc-no-arc for ARC-enabled projects. Sorry for rejecting this commit :)
I don't see how you can prefer the compilation flag unless you consider your code to be legacy code. The point of the commit is to support ARC — seamlessly, without breaking older apps. Granted, it's a small project, but it's still information to maintain.
I personally don't like this kind of #ifdef in code, but you must be right. Seamless integration will be appreciated by the newcomers.
Thanks. I don't like ifdefs either, but new projects have ARC enabled, and you will get a compilation error if you don't edit the compilation flags.
Thanks for understanding and insisting on this pull request. I much appreciate :)
@alexstaubo This commit complicates future maintenance.
I would suggest instead wrapping the code in retain/(auto)release calls and define them as no-ops for when ARC is enabled.
See XCMemoryUtils.h for an example of such macros.
Also see how that file tests for ARC: We could be building on a compiler w/o the __has_feature function, so we need to test for that as well.
Not sure what kind of future maintenance you are thinking of, but your project is 302 loc, not exactly a maintenance nightmare? What makes most sense in my view is to fork the code into a (frozen) legacy branch and a current one. Unless you plan on maintaining the legacy non-ARC version?
I don’t care about how big the project is or how likely we currently think it is that the code will be changed, adding redundancy is never a good idea!
As for a frozen non-ARC branch, that certainly beats the inline duplication, but I reckon there’s still a lot of software out there not on the latest toolchain (I think you need to build with 10.7 SDK for ARC), so just handling this via macros seems the better choice to me.
That said, this is not my project, I am just providing feedback.
(Sorry, didn't see who was replying, assumed it was @shpakovski.)
Thank you for the feedback guys!
XCMemoryUtils.h promotes a good idea, but using macros like RELEASE and AUTORELEASE looks even worse than using #ifdef to me. Overall I think that people who are going to reuse this component on the old systems, will have enough experience to change current approach to be compatible with a compiler missing __has_feature.
Let's live with current code :)