David Heffernan

I have my own functions that call the task dialog api rather than using the VCL component.

You don't need a component on a form

Isn't this a VCL styles bug? Won't happen with plain windows theme.

Why don't you let us give you extra sets of eyes?

Perhaps I misunderstood the point you were trying to make, but that pattern of returning a newly created instance, with a Free in the except block is useful. Even then the FreeAndNil isn't needed because Result is not seen by the caller.

Not really. The call to LoadFromStream could fail.

Yes there is. I explained what was wrong in my first comment. The try of the try/finally is before the local variable LTextFile is assigned, but it should be immediately after it.

I don't think the issue is complexity, the example is fine. it's just a couple of minor inaccuracies. That said, I'd strip out the FileExists check and just focus on the exception handling: LTextFile := TStringStream.Create; try LTextFile.LoadFromFile(AFileName); Result := TMemoryStream.Create; try Result.LoadFromStream(LTextFile); except FreeAndNil(Result); raise; end; finally LTextFile.Free; end; If you'd like people to comment on the entire book, do ask!

This looks very interesting. After a quick skim of one topic on I note that there's an error on page 89 that is worth addressing. LTextFile is protected by a try/finally but created after the try rather than before the try. In that example I'd also put the try of the try/except immediately after the assignment to Result rather than two lines before it. For what it is worth I'm sure that if you had posted here then quote a few people would have read your book and looked for errors and given feedback. I would happily have done so and would still do so.

vtune with map2pdb is excellent. It will take time to set it up, but it will save you time in the long run. And you'll have a better end result.

Yes. Use a buffered line reader. But more importantly measure where your code spends its time. Don't guess.

Sounds like you need to build some messaging infrastructure in to your program.

Regarding the code in the previous post, every call to Delete performs both a copy and a heap allocation. You should be able to do this with one heap allocation and one copy.

Why isn't the function call mapping to the native TaskDialog and so letting the OS provide the captions?

No. There is no problem. If there are multiple threads then the OS will schedule them into different logic processor cores. Always has. You misdiagnosed your problem before.

The entire point of a threads are to allow code to execute in parallel in the same process.

Make a minimal example that we can run. Or just debug your code.

Yes, through context switches the OS preserves the CPU and FPU state which is part of the thread context

I set the floating point control state to the Windows default (which masks exceptions) before calling any external library, and then restore it when those calls return. In order for this to work reliably in a multi-threaded environment you need to do some serious RTL patching to fix the thread safety issues. No, it is possible to fix the RTL so that you don't require such an invasive solution as you imagine. My numerical software does this. Many years ago I submitted a QC report with the attached document which explains how to fix it. Embarcadero have done nothing yet, although deleting QC meant that my report disappeared from public view! Rethinking Delphi Floating Point Control Register Management.pdf

Sure. But there are plenty of methods where you can make changes. Just because something doesn't solve all problems, doesn't mean that solving some problems isn't possible or useful. But for sure in an ideal world we would have in, out and in/out parameters implemented with the same functionality as C#. I'd be very happy to have a breaking change to the compiler and migrate my code to such a language.

Indeed. And it is simply the fact that var serves as both in/out and out that explains why there is no such warning for var parameters. Since we have out then a very simple thing for the designers to do would be to enable this very warning for var parameters too. If you encountered it on a var that was masquerading as a pure out parameter, you could simply change the parameter definition to be out.

Without the compiler enforcing it, it's next to pointless

The thing is, for value types, there is actually no practical difference between var and out in Delphi which is the problem. In practice out and var behave identically. So what's the point of out? I appreciate that legacy makes it hard to change. It was just a screw up by the designers that leads to oddities like the absent warning in this question.

A variable has to be initialized before being passed to a ref param

Because it has been designed correctly with ref, out and by value arguments handling the three different parameter semantics. C# is an example of how delphi should be, and the entire issue with this missing warning is because delphi is so badly designed in this area.