David Heffernan

My code uses FAN rather than free as a rule, and I don't recognise the problem you describe. That's my practical experience.

Wrong solution. Right solution is to learn what you don't know how to do. No shortcut. Certainly not by just saying "use interfaces".

This makes no sense at all. If you instead use Free and retain a stale reference to a destroyed object, then other code simply cannot know that the reference is stale. There are two main scenarios. Object destroyed by owner, either from another instance's destructor, or in a method with try finally lifetime. FAN is just a debugging guard against use after free. Or a reference to an instance whose lifetime is dynamic. Perhaps created and destroyed multiple times by its owner. Then nil is used to indicate the state that the object is currently not in existence. It seems bizarre to me that anybody could advocate carrying around stale pointers.

As you say, that's a problem with the developer rather than the function itself. I personally use FAN everywhere and my debug builds use FastMM with all bells and whistles. There aren't downsides to using FAN and it does make it easier to catch some defects.

You fix the bug, which is nothing to do with FAN. That's my point.

No it doesn't. How else are you going to allow constructors to raise exceptions?

Yeah, because delphi is so fast! But also, I doubt you could find a real program that would have a measurable performance hit even if the ref was set to nil always.

Amazing that there's anybody left that doesn't know that Free does the nil check itself.

That's a bug to use that reference, so this issue can safely be ignored with regards FAN.

As an aside, even in Delphi there is no such need. You can write 'first line'#13#10'second line' And even then, concatenation of literals is performed by the compiler, so the above code would result in the same codegen as 'first line' + #13#10 + 'second line' Finally, it is usually preferable to use sLineBreak rather than #13#10 so that your code is more expressive, and platform independent.

So instead of code like obj.foo := obj.bar + 10; you prefer obj.setFoo(obj.getBar() + 10); or perhaps obj.setFoo(obj.getBar + 10); (note that I personally am not keen on being able to call a function without the parens because it leads to ambiguity for type inference)

These two statements appear in conflict with each other. Advocacy for using getter/setter methods directly, flies in the face of criticism that properties can't be passed as var or out params. Neither can methods.

Perhaps the data module isn't being destroyed. If you showed a minimal reproduction then we'd be able to tell.

The latter. If you include this gpl licensed component then that propagates.

There are times when this is desirable. It's a big weakness in my view that the type of a literal can be ambiguous.

Same for integers, right? We don't feel compelled to store pointers to integers in arrays very commonly, do we.

Pretty bad idea this. It's also attempting to solve a problem that doesn't exist. Like if I do this: i := 12; j := i; i := 14; I don't expect j to become 14. It's just value type semantics.

mLabelMatrix[i, j] or if you prefer mLabelMatrix[i][j] as documented in the link I gave you

That's odd because you already solved the problem properly. Why do you just give up?

LabelMatrix is a type. You need to declare a variable of that type. Why would you have a dynamic array if the dimensions are known. Also, why 11, 6 if it is 12x7. If it is a fixed size, declare it so. Structured Types (Delphi) - RAD Studio (embarcadero.com)

It's just a multidimensional array of record. You will need to decide whether it is zero based or one based, but your example above shows a range of at least 13 in the major axis.

Start from the actual program and remove things bit by bit. When you remove something and the behaviour changes, that's evidence.

It might well be difficult. But unless you are able to debug this yourself what option do you have. In fact if this was my code and I was debugging it, making a minimal reproduction would be how I would tackle it.

Can you cut this down to a minimal reproduction

Well, slipstream them in too. You should be able to deliver an environment that has any packages you need.