One more reason to have an ARC win32 compiler: tracking down memory leaks efficiently
Posted by jpluimers on 2018/06/07
One of the reasons it is so hard to write ARC a compatible source base is that there is no Delphi ARC win32 compiler. So you have to debug your memory issues using the remote debugging capabilities which – besides very slow – are unstable at best.
This is the number 1 reason I have been asking for a Delphi ARC win32 compiler integrated with the native Delphi win32 debugger (in addition to the current Win32 non-ARC compiler). Hopefully [WayBack] A second example of memory usage/leaks on linux using TTask (but only running one at a time) inside a loop will show memory usage increasing depending o… – Andrew Pratt – Google+ will give Embarcadero more motivation to eventually develop one.
This besides the fact that anyone writing for ARC should buy+read [WayBack] Delphi Memory Management eBook for classic and ARC compilers
via [WayBack] I have some questions about Linux & ARC and I’m hoping some experts can share their expertise because I’m not understand the results I’m seeing. For th… – Andrew Pratt – Google+
(see also [WayBack] How to free a component in Android / iOS – Stack Overflow and Delphi ARC: Free versus DisposeOf (via: Ondrej Pokorny – Google+))
–jeroen
The Wiert Corner - irregular stream of stuff 
Paul TOTH said
A non-ARC compiler for Linux & Mobile is also a solution 🙂
Alexandre Machado said
The medicine is not working, let’s double the dose? The reason why you need to debug your Delphi ARC-enabled code using the real thing is because your existing Delphi win32 code won’t behave exactly the same when you build it in an ARC-enabled compiler. You are unable to run your Win32 code in a Windows machine and discover why it is not working in ARC. And you are proposing, as a solution, to make all the Delphi code in the world to break, so it is simpler to find those issues? I’m afraid you are not kidding but I wish you were.
jpluimers said
I have made the post more clear as I am proposing a Win32 ARC compiler in addition to the current non-ARC Win32 compiler (I supposed “have” in the post title would imply the current non-ARC Win32 compiler to stay, as it would indeed be really bad to replace the current non-ARC Win32 compiler with an ARC one, but apparently that needed more clarification).