Delphi Programming Tips & Tricks

After extending Delphi PRO SKU with mobile platforms, more great news from Embarcadero!

The introduction of Delphi Community Edition (CE)
A free PRO level version of Delphi and C++ Builder targeting hobbyists, open source developers, small startups..., anyone that does not make more than $5000 a year from using it.

Since CE license is restricted to 5 or less instances on network, the Academic program is still available for training purposes.

Enjoy!

LinksDelphi Community Edition Landing Page
Delphi Community Edition Download Page

C++Builder Community Edition Landing Page

C++ Builder Community Edition Download Page

Community Edition FAQs

Community Edition Eula

Community Edition Docwiki Page

Feature Matrix

Moving from Community Edition to other editions and moving from Starter to Community Edition

Dear Gaia,
I admit. I'm weak. I caved in. Please forgive me!
Sincerely,
Dalija


I hope Gaia will accept my apology!

I caved in to popular demand and have released a dead tree edition of my book. The first prints just came from Amazon (.com not the rain-forest... not sure about the origin of the paper, though...), and the book is ready for sale in its paperback form!

You paperback lovers, you...

You can find several ordering options, from eBook (PDF, epub, Mobi, Kindle all together at $37.50), single license or multi-developer site license, to Paperback (via Amazon, $45) and the bundle of both eBook & Paperback (ePixEditions/FastSpring and Lulu, together $60).

You'll find all of this at: http://dalija.prasnikar.info/delphimm/index.html

Catching memory leaks on the ARC compiler can be a daunting task. Even if the destructor of an object instance is called, that still does not mean your object is completely released.
In the classic desktop compiler, a quick test to see whether some object instance was released or not was to add a breakpoint (or some logging code) into the destructor, and if you got there, all was good. This is not the case with the ARC compiler.

The last method called in the object instance lifecycle after which all instance memory will be completely released is TObject.FreeInstance. While this method is common to both ARC and classic compilers, on the classic compiler executing the destructor would inevitably (unless it throws an uncaught exception) mean executing FreeInstance and completing the release cycle. On the ARC compiler, there is no such guarantee. The destructor can also be called directly via DisposeOf, and FreeInstance will be called only after all strong references to the object are c…

First of all, Delphi developers don't know how to Git the princess, they only know how to Subversion.



You are an experienced Delphi developer with 20+ years in the field. Actually, there are no other kinds of Delphi developers. You know how to save the darn princess. You are done while others are still prototyping.

You use FireMonkey to git the princess. You accidentally trip over the undocumented dragon sneeze button. Now, the castle is on fire, the princess in on fire, you are on fire...

You start on Saturday, there is a new Tokyo update. Godzilla jumps out of it, demolishes the castle, makes the dragon run for his life, and squashes the princess.

You start on Saturday, there is a new Tokyo update, and it triggers a license check error with an ancient Delphi 7 installation. While you wait for Monday to get support, others have pulled the princess and there is none left.

Inspired by https://toggl.com/programming-princess/

Mixing objects and interfaces in classic (non-ARC) Delphi is a huge no-no. That part is clear. What that actually means is more of a blur. After all there is a object instance lying behind every interface reference.

So what is wrong with mixing objects and interfaces?
object references are weak, interface references are strongreference counted object instances need at least one strong reference to keep them alive therefore you can't use object reference as primary owning referencereference counted object instances can be safely accessed through temporary, short-lived (weak) object references, as long as there are strong reference(s) keeping the object alive

The real issue behind the mixing of objects and interfaces is not the mixing itself, but the lack of initial strong (interface) reference to object instance, or accessing the reference counted object instance through weak (object) reference after the last strong (interface) reference has gone out of scope and the object has alr…

In Delphi, the [weak] attribute is used to break strong reference cycles between reference counted object instances. It can be used with the ARC compiler on both object and interface references, and with the classic compiler for interface references. Weak interface references were introduced in Delphi 10.1 Berlin.

Now, there is a teeny-weeny problem with the [weak] attribute. It denotes a zeroing weak reference that will be zeroed (niled) when the object it points to is no longer valid. In order to do that, the compiler has to track such objects at runtime and that introduces some overhead. If you are tracking many such references, that can introduce a significant performance loss.

Not all weak references that serve the purpose of breaking reference cycles need to be zeroed out. If you can guarantee that a [weak] reference will never outlive the object it points to, all that tracking and zeroing is useless. To avoid a performance penalty in such cases, you can use the [unsafe] attribu…