The ARC vs non-ARC situation adds yet another layer of complexity to creating cross platform code. The Linux compiler uses ARC – while Windows and OSX do not.
Guess what that does to the Linux support: It falls way down on the viability list for cross platform code for servers and services. Note that I don’t mind ARC – I just don’t get why they did not move to ARC for all platforms.
They could duplicate the libs, put the old ones into care & maintenance, and introduce
and so forth…
The current situation is pretty much ridiculous.
Edit: Added what I wrote in the EMBT forums.
I do not expect my non-ARC code to behave on ARC. It is after all a very different life cycle management model.
If you expect to be able to take your non-ARC code and move to Linux without changes – you are delusional.
My gripe is that I can’t really go cross platform now with the non-ARC Win32/Win64/OSX compilers. There is no way I want to maintain code that have to deal with both ARC and non-ARC life cycle management. I want to be able to have cross platform code – across ALL platfoms – without having to think ARC/Non-ARC.
I believe an ARC compliant FMX/VCL/RTL and ARC compiler on Windows and OSX (in addition to the current non-ARC) would offer the most sensible migration path for those that want cross platform, since there is no chance that the iOS and Android compilers will go non-ARC.
For those that don’t want ARC, they have to sacrifice cross platform compatibility, and probably risk a deprecated platform in a few years.
For those that want cross platform compatibility, they may have to sacrifice a bit of performance with the added complexity of ARC.
Note that the current performance problem on Android looks a completely different issue – i.e. not ARC related, since the previous versions also used ARC on that platform.