Leaderboard

Static class methods miss the implicit Self parameter, which holds the current type called. They are quite similar to global procedures/functions and therefore they cannot be virtual - there is just no VMT available. It is the same reason why static class methods cannot call virtual methods.

FWIW, here's an example of improper use of FreeAndNil causing a race condition because a context switch happened between between the nilling and the free: https://supportcenter.devexpress.com/ticket/details/t812550/an-av-occurs-if-the-spell-checker-whose-usethreadedload-property-is-set-to-true-reloads

If the callback runs in the background thread then FreeAndNil will not make the difference. In other words, your guard is not guarding anything. The FMyVar could be released after callback passes the Assigned check. You would need a different mechanism to protect your variable and make sure it is still alive while callback runs. The whole idea that your object which is still used while there may be pending async code running is a serious design flaw. I am not sure how easy would be to fix that code (I expect it is more complex in real life scenario), but you have a problem here. There are different mechanisms that can protect your instance, but which one is the most suitable will depend on other code and context that you haven't mentioned here. You can find some ideas at https://github.com/dalijap/nx-horizon look at how TCountdownEvent is used. another one is in https://github.com/dalijap/code-delphi-async/tree/master/Part6/35.2 GUI Cleanup but that one will work only if the TMyClass instance belongs to main thread. Of course, those are not the only solutions, just something to get you started. I haven't mentioned the most obvious one (waiting for the background thread to finish, before you release TMyClass instance, but I guess that this is not an option here or you would probably use it already.

FreeAndNil is something that you will need to use rarely (it might depend on the kind of code you are writing). In places where your code needs it logically it will be obvious that you need it and everywhere else you can use Free. The point that FreeAndNil can help you avoid errors and mistakes is full of holes. First, simple access after Free is usually easy to catch either by looking at the code (local variables) or by using memory manager in debug mode or other specialized tools. Next, FreeAndNil nils only single reference to the object instance. If you have multiple ones you will still have to deal with dangling pointers and you will need to learn how to use previously mentioned tools. Most of the problems with memory management in Delphi are caused by having multiple references to single manually managed object instance as such code is more complex. This is exactly the place where FreeAndNil cannot help you, but where using it will give you false sense of security. Another reason against using it everywhere, is that it obscures the code intent. Logically, FreeAndNil means that variable will be reused and this is important information. If you use it everywhere, you will have mush harder time reading the code and understanding its intent. And code which is harder to understand is also harder to maintain in the long run. Of course, that can be solved with comments, but then you will have to use them everywhere or you will never know whether some comment is missing somewhere. Manual memory management requires some discipline. thinking about the code you are writing enforces the discipline and makes you a better programmer. Taking the "easy" path where you will slap FreeAndNill everywhere just so you can avoid accidental mistakes and thinking is going to cost you at some point. Many existing codebases where it is used everywhere cannot be easily migrated to not using it as it can be hard to determine where it is needed and where it is not (except for local variables) and they need to continue using it indefinitely in all places, as the only thing worse than using FreeAndNil everywhere is using it randomly. Consistence in code is the king. In my codebase I have less than 50 places where I am using FreeAndNil (I cannot tell the exact amount as I have many smaller projects and it is not easy searching through them as some contain fixed VCL code which uses FreeAndAil a lot, so I cannot easily count usage in my files only) One of the advantages of being a new Delphi developer is that you don't have a lot of existing code where FreeAndNil was used in places where it is not needed and now is the right time for you to decide whether you want to pollute your code with FreeAndNil and stick with it forever or not.

I always use FreeAndNil, even if it is the last line of a method. Why? Because my code evolve, I can copy/paste it somewhere, add line,... If the object variable (Actually a pointer btw) is nullified, I'm sure I'll get and exception if I forgot I can no more use that object reference. The impact on performance is nearly null. But all rules can be ignored sometimes...

Against my better judgement I have submitted an issue report.