David Heffernan

Can I ask why you are interested in complexity of this algorithm? If it is for the sake of learning, fair enough, but there are far better examples to teach you. If it is for a real application, complexity is the wrong question to ask.

Very hard to find them though, and so easy to find good compilers.

Practical for small amounts of code that is seldom modified. Of course good compilers typically produce better code than humans can manage.

I'm not talking about the runtime. I'm talking about the code emitted by the compiler when it compiles my code. Performance is critical for my program. Some of the critical sections of code I translated to C in order to reap significant performance benefits of having a good optimising compiler. So yes, this is a real issue.

The complexity is linear with the number of digits. In this case it's probably much easier to write the code if you convert each number to text. You then need an array of counts for each digit. Count the digits. Finally check that each digit has the same number of occurrences. In practical terms, complexity arguments aren't actually going to be relevant here. It's the constant of proportionality that will matter most in performance.

I see pretty much the same code in 10.3 as produced by XE7 in my real world app, using the Windows x64 Delphi compiler. Performance is identical. Still significantly worse than could be achieved by the mainstream C++ compilers. Probably worse than what could be achieved in C#!

Runtime optimisation only helps if your code relies heavily on the runtime functions that have been improved. And where are these improvements in the code emitted by the compilers? I've not seen anything. What has changed?

It's more complex than that. Maybe for users of System.Generics.Collections. But what about those of us that write our own generic types?

Is it the case that Delphi apps are still locked out of the app store because there is no 64 bit Mac OSX compiler?

You never need to set a pointer to nil.

You said that the objects were instantiated by calling the constructor. You later say that they are loop variables used when iterating over a collection. So that's a total contradiction. So, with this new information the simple answer is that you never need to set the loop variable to nil. We read the question just fine. Please don't tell us to read it again. It's you that should read it again.

That's the not true part of what I am saying. There's also the not helpful part of what you stated. I found your comment to be entirely unhelpful.

That's not true, and not helpful. The function can return anyrhing it likes. No reason where there has to be a field anywhere whose value is returned.

Somewhat ironic that the output that performs worse is the one that you found impressive.

C++ compilers are generally far better at optimisation than any Delphi compilers

When facing terminology that you don't recognise I cannot recommend the use of websearch highly enough. https://enterprisecraftsmanship.com/2016/07/27/what-is-an-implementation-detail/ https://stackoverflow.com/questions/1777719/what-is-the-definition-of-an-implementation-detail And no, it's the second excerpt that relies on leaking implementation details, which is why it should not be used.

Time to stop digging.

That's not nonsensical from the programmer's perspective. Only from the constraints of the language design. I'm coming at this with an open mind as to what a programmer would like to be able to do. You are tied down by the historical precedent of syntax. The fact that [1,2] can be an open array constructor, a dynamic array, or a set, depending on context is the root of the problem. It is that poor design of the language that is at the root of this question. So I object to your defence of the language and assertions that what the programmer wants to do is nonsensical. I struggle to understand these two claims of yours: 1. A plain function is a better way to implement an equality test than an operator. In my view that is an indefensible claim. You have to use a plain function because the language syntax doesn't support an operator. But that doesn't make the operator undesirable. Just unachievable. 2. An operand that is an array implies more than two operands. I can't work that out. That's why I though you don't know what a vector is. But you seem to have got past that in your last post where you happily use arrays as operands.

It's almost as if you don't know what a vector is.

Even on windows, IsDebuggerPresent is not the same as System.DebugHook <> 0. The former tests for any debugger, the latter tests for the Emba debugger.

An array can be thought of as a single entity. Consider vector arithmetic. Take two vectors of length N and sum them. That's one operator, two operands, each operand a vector with N scalar components. My entire livelihood is based on such a form of mathematics. Are you saying I've been doing it wrong?

There are only two functions, the A and the W version. The A version converts the input text arguments to Unicode and calls the W version. That's always the case with Windows. The A function is just a time and memory consuming wrapper around the W function. Note that this implies it makes no difference to the output of the created process since the W version is always going the work in the end. Basic rule is always call the W version. It's more efficient, the system is Unicode natively, and the W version means your code can be used by non English users.

You see Chinese text when you expect Latin text if you interpret 8 bit ANSI text as though it were UTF16 text.

So far as I can see, EXE packers bring cons but no pros. They are simply tools for making your program worse.

Dude, an array doesn't have to mean a range of operands. An array can be viewed as a single thing. Also, it's entirely possible to imagine useful operators with more than two operands.