The ARC vs non-ARC situation adds yet another layer of complexity to creating cross platform code.

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

arc.system. *

arc.vcl. *

arc.data. *

and so forth…

The current situation is pretty much ridiculous.

/rant

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.

49 thoughts on “The ARC vs non-ARC situation adds yet another layer of complexity to creating cross platform code.


  1. Paul TOTH – Initially, I felt the same. But, ARC modernizes our coding away from micro management and is forward looking. Also – being able to share code from back end to front end (iOS, Android) – is a major plus too.


  2. They didn’t move to ARC because they are afraid majority of Windows users that don’t care about other platforms would vigorously complain…


    It is damn if you do damn if you don’t situation.


    In the long run unifying memory management is the only viable option and since ARC compiler is newer that inevitably means ARC on all platforms.


    As long as there are two compilers ARC development experience will be suboptimal. And even when non-ARC compiler gets retired, there will be another breaking change required – refactoring of TComponent notification system.


  3. Paul TOTH They could still use the non-ARC version of the libs. Migrating non-ARC code to ARC is trivial compared to trying to make the same code reliable under both ARC and non-ARC.


  4. Dalija Prasnikar For us, it means that Linux is still-born. After having tested for parts of our shared code – battling with the ARC/non-ARC issues just is not time well used. A double coding standard is no standard at all.


  5. This damn argument being held over and over and over has to stop. I wonder for how long Delphi developers want to manually manage their object instances. Are we still in the 90s?


    Is the current implementation of ARC ideal? Hell no. Why would we ever want to override __ObjAddRef or __ObjRelease? Make them non virtual inline and save a couple percent of performance in some systems (or even cooler let the compiler optimize away useless virtual method calls when it sees that it was not overridden anywhere that would not only benefit this part!). Give us control over capturing things in anonymous methods so we don’t end up creating memory leaks without knowing.


  6. Stefan Glienke Without ARC, in Delphi, you are not required to manually manage object livetime: you can use TComponent ownership, smart pointers, or auto-release value objects using RTTI – see TSynAutoCreateFields in https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITLE_610


    Even with ARC, you have to manage object instances, just by taking care of weak references. Even if you don’t need to write try…finally aObject.free; end; blocks of code any more doesn’t mean that you still don’t need to manage object instances.


    You are right about anonymous methods weird capture, but with ARC or GC styles, you still can easily create memory or resource leaks – very difficult to catch. I tracked such leaks in C# server code for weeks… 🙁


  7. A. Bouchez TComponent ownership is way to heavy for many things. As for TSynAutoCreateFields we have something similar in Spring4D called TManagedObject that can create aggregated objects and initialize fields that are annotated with certain attributes.


    Anyway even with all those tools it can become quite cumbersome working with manual memory management especially when working with lists and moving and taking objects from one list into another while one of them has set ownsobjects. With ARC just simply the last list containing them causes destruction if the object is not referenced anywhere else. Sure you can implement this reference counting mechanism onto your own lists but then if you pass around the objects you still have to call the refcount code manually.


    Juggling with lists and enumerables is so damn easy in C# (sure it does not use ARC but a GC but nevertheless) while in Delphi you often have to waste time with banalities.


  8. Stefan Glienke We do agree on this, of course. This is why I like arrays of records for storing value objects. They have the reference counting mechanism built-in, and efficient storage.


  9. Nobody will “invest” to move huge Delphi code bases to ARC. Is it simple? NO it is NOT. If it was simple, then what’s the problem having 2 different code bases, one ARC and the other manual managed? The fact that you are discussing this here, proves what lots of users have been saying for a long time: It is not simple to keep a single complex codebase compiling with and without ARC. The day that Delphi imposes ARC on Win32/Win64 compilers, that day will see lots of companies leaving Delphi for good. Instead of rewriting it for ARC they will rewrite it in C#. That’s a fact.


  10. Yesterday, Jon L. Aasenden (the guy behind SMS), posted on Facebook that the company he works for is dropping 30+ Delphi licenses. Is it because of ARC? Is this because of manual memory management? NO! That’s because Delphi built-in XML mapper cannot handle most XML schemas used by governments all around the world. EMBT should focus on the COMPILER (generate better binary code that won’t embarrass us in front of JavaScript programmers) and do the basic stuff work as it should!


    This is the post: https://www.facebook.com/groups/137012246341854/permalink/1397049440338122/


  11. Ralf Stocker No it wouldn’t, or rather, not by virtue of ARC in itself – the existing compiler for the iOS simulator isn’t 10 times slower than the existing compiler for macOS, which is a like-for-like comparison.


    Alexandre Machado ‘It is not simple to keep a single complex codebase compiling with and without ARC. ‘ – Exactly, that’s why people are asking for an ‘all or nothing’ ARC option on Windows as well, so they can choose to enjoy one cross platform language mode if they so wish.


    ‘Delphi built-in XML mapper cannot handle most XML schemas used by governments all around the world.’ You’re contradicting yourself. What’s the XML mapper got to do with the compiler? It’s not even a library feature – it’s exactly the sort of thing a third party could do well with zero Embarcadero support.


  12. Chris Rolliston “It’s not even a library feature – it’s exactly the sort of thing a third party could do well with zero Embarcadero support.”


    You should write to Jon Aasenden employer and explain to them why they shouldn’t expect to pay 4K for a tool that can’t handle XML (which VS does in a blink of an eye), and they should pay a third party company to do that. Maybe they buy this bla-bla-bla… who knows?


  13. Alexandre Machado​ you were trying to argue against the claim that Embarcadero should support ARC on Windows. Doing that is ‘basic’ in the sense that core ARC functionality is only something they can do however; in contrast, writing a tool to generate XML mappings is ‘basic’ only in another sense, given the task is something that anyone, in principle, could do.


  14. Alexandre Machado Main issue with ARC is keeping compatibility with non-ARC compiler. Another issue is lack of Windows ARC compiler that would help in finding bugs customers code as well as potential bugs and issues in ARC compiler and core frameworks.


    With single compiler transition to ARC would be much smoother. And I am not saying that it would not require some work.


    In the long run having ARC compiler would make basic development easier and faster because no matter what people say or think, managing memory under ARC is way easier than managing it manually.


    It is transition that is painful, for one reason or another, not the end goal itself.


  15. Attila Kovacs ARC doesn’t help you find bugs. It helps you avoid creating bugs. It reduces the need for manual allocation/deallocation and manual referencing/dereferencing.


    Fewer try/finally blocks. It’s no silver bullet, but it is another step away from assembler.


  16. Lars Fosdal Thought so. And a very cool description from you thx. Just a last stupid question, is there also a ReportMemoryDidntGoOutOfScopeOnShutdown(), or WhyIsMyAppEatingUpTheWholeMemory()?


  17. Attila Kovacs Yes, it’s called unit or integration testing with memory leaks checking.


    Funny example: obviously now with Linux people found some memory leak in FireDAC (see https://quality.embarcadero.com/browse/RSP-17331) which already had been reported and found while doing unit tests on mobile platforms during Spring4D development (see https://quality.embarcadero.com/browse/RSP-13657 which was unfortunately closed as test case error)


    You can find some more ARC related issues being reported by Jan which he found during unit testing Spring4D on mobile and developing his LeakCheck library (Honza RameĹĄ FYI).


  18. A copy of what I wrote in a thread on 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.


  19. Lars Fosdal Fair enough. However, what about 3rd party component vendors. Think about DevExpress or TMS with giant code bases. Let’s say you use a DevExpress grid in a Win32 application which you intend to port to ARC. But your neighbor, which also uses DevExpress, thinks that moving to ARC is a waste of time (Personally I think your neighbor is smart! 🙂 ). What now?


  20. Alexandre Machado I see three outcomes.


    1. They keep doing non-ARC, and risk losing customers that want ARC


    2. They make two versions – sold separately, perhaps


    3. They switch to ARC and put non-ARC into care & maintenance


    In many ways similar to any other tech paradigm shift.


  21. Warren Postma It all started with Windows ARC compiler. It already exists. And AFAIK adding full ARC to compiler was rather easy.


    I am more worried for other compiler features and who will design and implement them.


  22. That’s technically true and it’s not what I meant. You would then have to fix the myriad of edge cases, RTL and VCL bugs, and incompatibilities, and be able to support the results in production.


  23. When you add more platforms, the “cubic feet” of volume that you have to cover to keep the product functional grows. There is already delphi 32 bit classic, delphi 64 bit classic (non LLVM) and the various LLVM based compilers, plus the various C++ compilers (LLVM and classic). Adding one more compiler/platform combination, testing and releasing a working product with all that, is probably something that strains the remaining team. I am surprised (happily) that the Tokyo linux platform shipped. And even if I see people using it happily in production, I’ll remain skeptical about its long term future as Linux evolves. Right now it supports two linux distros out of about 200 in common use. Great. That’s two more than we had last year at this time. I hope this works. I won’t be surprised if it fails.


  24. Warren Postma – Many of the different Linux versions are derivatives from RH and Ubuntu. I’ve tested Delphi on CentOS, and others have tested it on Debian. The number of supported versions depends basically on establishing which prerequisites that are needed.


    I think it is a major mistake to not ship Linux support for Professional.


    I think Linux SDKs needs to be user configurable to allow people to try to incorporate currently unsupported platforms.


    I think we will need more ARM versions of the compilers, to support more devices (Pi, Arduino, etc)


    But – Most of all – I think it is a major mistake to not select one single life cycle management model across platforms and permeate that model throughout the ecosystem.


    Yes, transition will be a pain – but we are in pain already.