The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,184 other subscribers

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+))


3 Responses to “One more reason to have an ARC win32 compiler: tracking down memory leaks efficiently”

  1. Paul TOTH said

    A non-ARC compiler for Linux & Mobile is also a solution 🙂

  2. 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).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: