David Heffernan

No memory leaks when I run your code. Can you provide a minimal but complete example that we can compile directly.

No it won't. If the constructor fails then an exception is raised before the try / except is active.

Can you provide a minimal example that demonstrates the issue.

You are right, I misread the code.

Your code doesn't call Free if an exception is raised, when you pass nil as the owner. When you pass the form as an owner, the form destroys the owned object when the form itself is destroyed. You need to learn how to use finally blocks. This is a fundamental pattern that is essential knowledge.

If you try to use a DLL rather than a package, then it won't work. The simple way to think about it is that your GUI code and the components all need to share the same instance of the RTL and VCL. Packages enable that sharing. Plain DLLs do not. Yes you can. Many of us do that all the time. Is it really too much to ask why you think you cannot compile third party code into your main executable? If perhaps you think that licensing is the issue then I doubt that putting the code into a separate dynamically linked module changes anything.

Plain native DLLs aren't really practical for components. This is the reason that packages exist. So if you need the code in a separate module, use a package. But packages introduce complexity for deployment and versioning. Why don't you want direct inclusion of the code in your executable?

Don't. Best option is to compile it directly into each project. Next best is to compile into a Delphi package. Direct inclusion is much more simple.

Wouldn't it just be better to stop using XP? Doesn't even sound like you have a machine to test on which is tough for a program based on USB devices.

Then it sounds like the issue is with your USB library. You'll need to dig into this, but my expectation is that the Delphi runtime won't call that function, so it's your code that does. You'll be more experienced once you solve this!!

Why are you calling SetupDiGetDeviceProperty?

Imagine if we could specify the type of a literal ........

It depends. Get XP and try it.

This is it then isn't it. What's in the real program that causes the misbehaviour?

I don't experience this in my program. Can it be reproduced?

This should just work. The real question is why your modal message box is not on top. You should try to work that out.

No. The scheduler will put the tasks onto different threads for you. No. It means that the main thread is doing nothing, but since there are as many worker threads as cores, the CPU will be fully busy. No. Looking at your code, I guess you need to generalise it to work with an arbitrary number of tasks. This will require you to use some arrays in place of variables named 1, 2, 3, etc. It also looks like you are doing floating point division and I'm not convinced that you will count every single character, and also that you won't count some characters twice. I think you need to be more precise about the bounds of each task's work.

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.

True. But then I've never made that claim.

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?