David Heffernan

It's not double the work.

I would absolutely not want syntax like that. If that's the way you want to go you can do it today with generics. In an ideal world I'd like to see the generality offered by C++ templates though. That would allow algorithmic programming that is just too painful with generics.

You mean with the code from OP?

This seems worse than method overloading to me. There you have compile time branching. Here you have to perform runtime type checking.

I don't think so. You want to be able to define a default FPCR for new threads, so just making those vars threadvars doesn't achieve that. But in any case, why have threadvars for something that is already part of the thread context? That makes no sense to me.

That's a different race though. At least when you call Set8087CW then you know what happens in your thread. But you can still end up modifying things in other threads I guess.

No. That can result in a change to the floating point control state in a different thread, due to the data race on the global var.

32 bit processes on Windows aren't going away anytime soon. It's actually not hard to change the runtime to address these issues, which can effectively be summarised as isolating threads from each other's execution contexts. I would imagine that Emba don't do it because they perceive that the benefit is too small in comparison with other candidate developments. And remember that I'm proposing a breaking change in behaviour which always raises the bar. Personally I feel that it's important to build on solid foundations. We've just had a huge breaking change by the killing of ARC. So breaking changes can happen. And by the token that a minority of users care about floating point, breaking changes in this area won't affect many people. And surely those that are affected would by and large appreciate the change.

I don't think so. It's very important that code behaves the same way for both 32 and 64 bit compilers and indeed for the non Windows platforms too.

I have noticed that the list of units that the plugin offers includes those that are loaded but not visible in the IDE. In my case this means units loaded because of visual form inheritance. So with a base form and a derived form, suppose that you load just the derived form. Well, both of the forms are offered by the plugin even though the base form isn't visible in the IDE. Is that intentional?

That happens when the variable is destroyed, which is when the destructor is executed.

https://stackoverflow.com/questions/4618743/how-to-make-messagedlg-centered-on-owner-form

They both have seen the document already.

Rethinking Delphi Floating Point Control Register Management.pdf

Yeah, that's Quality Portal, the new place for reporting bugs. I submitted loads of reports at the old place, Quality Central, and then Emba killed it, along with all the bug reports. We were asked to resubmit the reports that we cared most about. Which was a load of work that I couldn't face.