Jump to content

David Heffernan

Members
  • Content Count

    2445
  • Joined

  • Last visited

  • Days Won

    131

David Heffernan last won the day on June 11

David Heffernan had the most liked content!

Community Reputation

1735 Excellent

Technical Information

  • Delphi-Version
    Delphi XE7

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Your argument about intent is the closest that I have ever seen to a cogent argument on this subject. But I still don't buy it. In your argument, if you see code that sets references to nil then that indicates this "optional lifetime" pattern, for the sake of inventing a name. And your point is that if you set the reference to nil every time you destroy an instance, then you can't distinguish the optional lifetime pattern from the two more common lifetime patterns, let's call them "owned lifetime" where the object is destroyed in its owner's destructor, and "local variable lifetime" where the object is created and destroyed in a local method, and the reference is a local variable. The thing is though, when you see FAN in owned lifetime and local variable lifetime, it's unmistakeable what the lifetime is. You never think, oh, I wonder if this might be optional lifetime. That's why I don't buy the argument, and why I've never experienced the issues you describe. What I have experienced though is the pain of using a stale reference. That pain is eased if the reference is nil. And yes, we can use debug MM to write over memory when an object is destroyed, but I don't want that to happen in my release builds. And sometimes bugs only emerge in release builds.
  2. True. But then I've never made that claim.
  3. My code uses FAN rather than free as a rule, and I don't recognise the problem you describe. That's my practical experience.
  4. Wrong solution. Right solution is to learn what you don't know how to do. No shortcut. Certainly not by just saying "use interfaces".
  5. 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.
  6. 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.
  7. You fix the bug, which is nothing to do with FAN. That's my point.
  8. No it doesn't. How else are you going to allow constructors to raise exceptions?
  9. 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.
  10. Amazing that there's anybody left that doesn't know that Free does the nil check itself.
  11. That's a bug to use that reference, so this issue can safely be ignored with regards FAN.
  12. David Heffernan

    Add #13#10 to a string

    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.
  13. David Heffernan

    Left side cannot be assigned to

    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)
  14. David Heffernan

    Left side cannot be assigned to

    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.
  15. David Heffernan

    TDataModule OnDestroy event never triggered?

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