David Heffernan

40 minutes ago, Sherlock said:

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

The problem with that is the the problems tend to interact with each other.

50 minutes ago, Anders Melander said:

Sure, but how is that relevant?

Are you saying that they have enough resources or that more resources will lead to more problems?

I'm sure that they have plenty of problems besides resources but surely their ability to solve them isn't improved by this shortage?

The point of the book is that adding programmers won't necessarily result in a better output.

1 hour ago, Günther Schoch said:

I am sure that Marco and the team is clever enough to solve a lot more problems and enhance the product if they get more money

It's far from that simple. I take it that everybody has read this:

9 hours ago, Mahdi Safsafi said:

Not always a bad code ! sometime you need to make a lock/release. So you must call the inherited in between and finally free the Lock object. Sometime you need to perform a notification, ... Just take a look at the RTL/VCL, there're many destructor that call inherited in between.

9 hours ago, Mahdi Safsafi said:

I didnt say its a good practice. All what I said there are some situations where its implemented. 

I can't reconcile these two statements. 

9 minutes ago, Mahdi Safsafi said:

Just take a look at the RTL/VCL

That something may be done in the RTL/VCL doesn't mean it is good practise.

4 hours ago, Kas Ob. said:

might help in recovering from exception in the destructor

Nothing can save you at this point.

OK, Scaled = False does change things.

Destructors must not raise exceptions. My personal view is that if they do then the best course of action is to terminate the process.

If you remove PixelsPerInch from the DFM then you'll find that your form layouts break different devs modify forms if their machines use different font scaling (i.e. DPI) settings.

In my workplace we handle this by requiring all modifications of forms to be made using a common font scaling setting.  

8 hours ago, PeterPanettone said:

However, your employer has to pay for the time you need to write overloaded code. (Though I assume you're a fast writer).

In the OP you also write an implementation for each different type. So where is the saving? 

53 minutes ago, PeterPanettone said:

Why make double work? The employer would like it if you need only half the time.

It's not double the work. 

1 minute ago, dummzeuch said:

Yes

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. 

3 hours ago, dummzeuch said:

Not necessarily. The compiler could generate a set of overloaded procedures for this.

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.

1 hour ago, Leif Uneus said:

Is it not enough to declare DefaultCW8087 et al. as threadvar?

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.

2 hours ago, Arnaud Bouchez said:

Fair enough.

😞

 

But FPC doesn't suffer from this race condition AFAIK:

    procedure Set8087CW(cw:word);
      begin
         default8087cw:=cw;
         asm
           fnclex
           fldcw cw
         end;
      end;

 

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.

14 minutes ago, Arnaud Bouchez said:

Is just calling Set8087CW() at thread start enough as a workaround in user-code?

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.

5 minutes ago, Lars Fosdal said:

But isn't everything moving towards 64-bit?  

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. 

12 minutes ago, Lars Fosdal said:

@David Heffernan - At this point in time, would it make sense to ask EMBT to focus primarily on the 64-bit part of this?

 

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?

55 minutes ago, Alberto Paganini said:

Where is RefToInterFace2:=nil invoked from?

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

1 minute ago, Lars Fosdal said:

@David Heffernan - I took the liberty of splitting this off into a new thread.
I think @Marco Cantu and @David Millington should look closer at this.

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.