David Heffernan

I think it's far more likely to be environment variables being inherited.

This sounds wrong. Messing with the system path and closing an ide tells me that you aren't creating and isolating your compile environments correctly. Note that Delphi is capable of building with any path and with any other ide open. You have solved nothing yet.

Not true. FValue, in your example, is available as soon as the instance has been allocated. Realistically the earliest you get to use it is inside the constructor.

No

Yikes!! Even leaving aside Stefan's point, functions that use a relative tolerance, relative to the comparands, mean that your comparisons depend on the path through the array. I think it very likely that inserting some extra values away from the target could lead to a different value being found. There certainly are situations where comparing to tolerance is useful. However they need to be considered in detail and the tolerance choice and surrounding algorithm must be carefully thought out. A one size fits all function like this is not useful in my experience. Furthermore, I would say that a lot of times I have seen tolerance checking, it comes from a misunderstanding of floating point representations. Tolerances get used when they aren't needed. Sometimes it's not entirely the programmer to blame. For instance delphi's string conversion functions are broken because you can't rely on a round trip from float to string and back to float. So if you save as json or YAML or ini, say, then you don't get back the original value when you load from text. This is intolerable for a serious floating point developer. And it often drives people to compare to tolerance. My solution is to use conversion libraries that work correctly. Emba know about the problem but unless I am mistaken still have not fixed the problem.

This certainly changes things!

Right. They do what they are meant to do. It's just that they aren't actually useful for anything.

Then you are going to need to work out what your problem really is. Because it hasn't been stated here. If you want to work with numbers that have a finite number of decimal digits, then use a decimal type. It is precisely why such things exist.

They are invariably used as "solutions" to problems caused by floating point representability issues, but usually are the wrong solution.

{$APPTYPE CONSOLE} uses SysUtils; procedure Main; var i: Integer; val: Double; begin val := 0; for i := 0 to 80 do begin Writeln(FloatToStr(val)); val := val + 0.1; end; end; begin try Main; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end. Output: 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.99999999999999 6.09999999999999 6.19999999999999 6.29999999999999 6.39999999999999 6.49999999999999 6.59999999999999 6.69999999999999 6.79999999999999 6.89999999999999 6.99999999999999 7.09999999999999 7.19999999999999 7.29999999999999 7.39999999999999 7.49999999999999 7.59999999999999 7.69999999999999 7.79999999999999 7.89999999999999 7.99999999999999 So yeah, not looking such a good idea now. Why not use integers. You just need to count how many tenths you have. That's the job of an integer. Once you recognise this, then you are 90% of the way to realising the right solution.

What I propose works and it's better to avoid strings here.

Neither. Spawn of satan, should never have been published. In your case do all the behind the scenes work using integers and then divide by 10 just when you need the actual value. Or use a decimal type like currency.

I'd definitely remove the pointer check you just added. Surely that's just going to make things slower.

Don't think performance is an issue with TArray<T> and using it makes you code better able to work with other generic code.

Any reason why you aren't using TArray<Integer>?

This risks range check errors so I'd use Pointer(A)^ and similar for B. You could still save one of the lengths to a local to avoid getting it twice.

Not much point having three calls to Length and in fact the zero length check can be skipped and rely on CompareMem to know what to do when passed a size of zero.

First compare their length then do a CompareMem if the lengths are equal

I once went into our local hardware store to buy a posidrive screwdriver, because I had to do something with a bunch of posidrive screws. The guy in the store scoffed at me and said that they didn't stock posidrive screwdrivers because posidrive screws were a stupid idea. This store is no longer in business.

Agreed, but the issue is not one of type safety, as you stated.

How are you expecting anybody to translate this without there being an agreed curl library. Do you know what curl is?

You don't need to be a C programmer to translate this. You just need to understand the basics of curl. Do you have a Delphi curl library to hand?

no extra type safety is gained by using a record over an array

Invariably this error is a 32/64 bit mismatch

Could you explain the requirement in more detail? I think that might help us understand how to solve the problem.