Delphi Memory Management Webinar

-

Join me this Thursday, Apr 22, 2021 5:00 PM - 6:00 PM CEST for a live Q/A session about Delphi memory management. See you! 



Register for webinar:

https://register.gotowebinar.com/register/474961949731996432


Book information:

https://dalija.prasnikar.info/delphimm 

Comments

  1. LachlanGApril 20, 2021 at 4:52 PM

    Here's some questions in advance for you (which I'll have to catch on the replay (hint, hint) due to timezones).

    What's your thoughts on The Wiert Corner's aversion to using AfterConstruction? (see his blog post 2021/03/23)

    For method parameters what data types do you make const rather than leaving them as a ordinary value parameter? These days I'm using const routinely for strings, interfaces and anonymous methods. I had started doing it for TObject descendants when there was the possibility of my code being run under ARC but I've since removed the consts from those.

    ReplyDelete
    Replies
    1. LachlanGApril 20, 2021 at 4:53 PM

      I forgot about records. I routinely const those as well.

      Delete
    2. Dalija PrasnikarApril 22, 2021 at 12:07 AM

      AfterConstruction is safe and IMO not used enough. Modifying base class and adding additional virtual DoCreate method is fine, too, if you have base class and you have reasons for not making constructor virtual. But, I would still prefer using it more for configuration than for constructing instances - in other words for final setup after you know all pieces of the object are fully constructed, but that also depends on particular use case. If you need speed, then using AfterConstruction rather than adding new virtual methods is faster.

      The only part where you need to be careful with AfterConstruction is with reference counted classes and triggering reference counting inside AfterConstruction after you called inherited method - that will cause self destruction of the object. See: https://dalijap.blogspot.com/2019/12/self-destructing-object-instance.html

      Also, regardless of the exceptions raised in AfterConstruction, full cleanup will run including BeforeDestruction and Destroy. So that part was not fully correct at least not for newer versions. In Delphi 7 BeforeDestruction is not called, but destructor is. In XE4+ both BeforeDestruction and Destroy are called.

      Anyway, since destructor must be able to handle cleanup of partially constructed objects anyway, BeforeDestruction is necessary only seldom, as anything created there can be cleaned up in Destroy.

      For parameters, I am following same logic you do. I also use it for larger records if I don't need to modify it - it allows compiler to optimize and avoid copying the whole record.

      Delete
    3. Dalija PrasnikarApril 22, 2021 at 12:09 AM

      I couldn't help myself answering your questions here... but I will mention that topic on the webinar, too :)

      Delete

Post a Comment

Popular posts from this blog

Delphi 12.3 Update

-
Image
The Delphi 12.3 update has just been released. The most exciting part of this release is the long-awaited 64-bit IDE. Now, this is only an Initial Release of the IDE, and it is not yet a full replacement for the 32-bit IDE and its functionality. The main advantage of the 64-bit IDE is that the available memory is no longer constrained by the 32-bit address space, and the upper limit is now the available system memory. The more you have, the more you can use. This is a great news for all developers with large projects, where the 32-bit IDE would easily hit the memory wall. To start with, the 64-bit IDE only supports the 64-bit Windows platform. The primary purpose of such a release with only partial functionality is to allow all component developers to update their design-time packages, and prepare them to support the 64-bit IDE. And to do that, you only need the 64-bit Windows platform anyway. For all other platforms, there is no immediate advantage of using a 64-bit IDE. As we all...
Read more

Celebrating 30 Years of Delphi With a New Book: Delphi Quality-Driven Development

-
Image
This year, on February 14th, Delphi celebrates its 30th birthday. Over the past three decades, Delphi has proven to be a robust and versatile development environment, empowering developers to build high-performance applications with ease across multiple platforms: Windows, Linux, Android, iOS, and macOS.  As we commemorate this milestone, I am also introducing a new book to help guide you into Delphi's fourth decade: Delphi Quality-Driven Development. Useful to lone developers and vast teams alike, this book aims to demonstrate a variety of essential practices and techniques for making high-quality, testable code. There is a 25% sale going on until the end of February for the Delphi Quality-Driven Development ebook, and there you can also get an additional discount on other books if you add them to your order. To all my fellow Delphi developers: May your code compile quickly, your memory be manageable, and your code testable.   Delphi Quality-Driven Development Book A practica...
Read more

Assigning result to a function from asynchronous code

-
One of the more common problems that comes up in multi-threading, especially when refactoring existing code, is assigning a result obtained from asynchronous code. In other words, how do you write a function that will return some value, and calculate that value in a background thread? Basically, converting the following code: function GetData(...): string; var Data: string; begin Data := LongTask(...); // assign result of a long-running task to a function Result := Data; end; To this one: function GetData(...): string; var Data: string; begin TThread.CreateAnonymousThread( procedure begin Data := LongTask(...); end).Start; // assign result of a long-running task to a function Result := Data; end; Now, the above code will compile, but it will not achieve the desired functionality. Even if we ignore its thread safety issues (the background thread writes to the Data variable and that can interfere with assigning it to the function result), the funct...
Read more