David Heffernan

Depends on what your program does. Try timing it.

I think Stefan suggests posting on Stack Overflow suitably tagged

No they are not

MaxInt

Nobody is going to be able to tell you what's wrong. You'll need to do some debugging. Does the issue occur when not using ReactOS?

They can only choose from these 14 items? Why do you need any conversion? Isn't it just (EndIndex - StartIndex) / 2?

The problem is that your code is based on an assumption that the end time is after the start time, but 00:00 is the beginning of the day and so can never be used as an end time. Hard to advise you what to do because we don't know your goals, where your data is coming from, how you want to handle day boundaries etc.

The error could be in code outside the destructor. So look in that code. We cannot see it.

If that is the case, then MaxInt should be used for that argument

I don't know what you mean here. Did you write this code? What problems are you having with the code?

That's what I would do, but it's just a needless nil check which a compiler could remove.

This statement is incorrect. The only way for Create to fail is if it raises an exception. The code is odd, but it doesn't do what you say.

If that code is from a destructor it's bizarre. Just call Free on each instance variable. But that may not be the issue, it would only be an issue if there were stale references in one of those instance variables. The issue may be a double free of the object. Or something else. Debugging required.

From what I can see, for the hardware that Delphi runs on, float64 is the largest float that can be operated on efficiently with CPU hardware instructions. float80 is available in the x87 unit, but x87 is very inefficient on modern processors. Do you know how float128 is implemented by compilers like gcc on x64 hardware? It's done in software. Presumably therefore it is slow. What real-world applications do you know of that require float128?

How are you going to implement a BLAS efficiently on today's hardware? What processors do you know of with efficient FPUs that handle more than float64? Forgive me if I am ignorant. I'm not talking about business apps. I develop a structural FEA code for engineers. Double precision is all that is required.

Excluding files from system directory sounds like a recipe for disaster! But yeah, make a 64 bit process. If you still need to support 32 bit OS then you need to supply one version for each OS.

Out of curiosity, what does your program do that requires users to select files in these directories which are private to the OS?

So yeah, I can't help you, I'm in the same boat as you

They must be breaking their own licence terms. They'd probably back down very quickly if threatened with legal action. When I faced this problem, reassigning a licence from a retired developer to a new hire, I had to use my personal contacts with the senior developer team to get it resolved. I don't feel great about having had to do this.

Well, because a/b is not necessarily equal to (1/b)*a. This is because a/b is defined by IEEE754 to be the closest representable value to the true value of a/b. Then (1/b) is the closest representable value to the true value. And then (1/b)*a is closest representable etc etc. So (1/b)*a has two roundings a/b has just one. In many applications these fastmath approximations are perfectly acceptable, but of course there are applications where this is a problem.

That's an interesting piece of work. And sure, if you need to perform arithmetic to higher than double precision, then double is going to be a problem. My point, poorly stated, is that I believe that the bulk of numerical computing doesn't need more than double. Is that not the case?

When I look to recruit people, I don't really care what technologies they've used. I am interested in how smart they are. But then I tend to be hiring for long term positions. So I don't even recognise a term like "Delphi dev".

Consider me confused

Why Delphi? Why not use something else?

80 bit was never for large precision. It was intended for use as intermediate values in calculations for accuracy purposes. But it turned out not to be worthwhile. That's why it has been dropped. The support in modern hardware for 80 bit is on the 8087 unit only and is horribly slow. It's there for legacy reasons so legacy code still runs. Perhaps you are doing different type of work from me. But I'm using BLAS type numerical algorithms. You don't find BLAS for 80 bit data. This is an interesting post https://retrocomputing.stackexchange.com/questions/9751/did-any-compiler-fully-use-intel-x87-80-bit-floating-point