David Heffernan

Recurring theme here is that you think that everything else is at fault when you can't achieve things that others can. Perhaps you need the curiosity to ask why this is.

Doesn't always exit with a Break

I actually don't know how that is interpreted by the compiler

This is a really good point, and very nicely expressed. Essentially the whole thing boils down to Delphi literals having ambiguity of type. Sets and arrays use the same syntax. For integers, what type is 1, how can I make sure that it is signed or unsigned, 8 bit, 16 bit etc. And 1.0, is that single or double? Why can't I state this explicitly. Other languages have these facilities, Delphi lags behind in this area.

Not sure who Dave is.... Delphi doesn't know that the type of the thing to the right of the equality operator is an array, it thinks it is a set. That's why you get the error. You might not like this, but this is just how it is right now. From the language perspective, there is clearly some magic disambiguation applied in the case of the assignment operator that isn't applied elsewhere. As Remy says, all you can do is to open a ticket. Shooting the messenger isn't going to get you anywhere. But even if the code did compile, what would you want it to do? For dynamic arrays, like other reference types, the equality operator = means reference equality. But I suspect that you would want value equality. So even if this code ever compiled, I don't think it would do what you want to do. In which case you will need to implement a method or function to perform value equality testing, and so the topic becomes somewhat moot.

I don't think your expectations are reasonable. You can't expect to mix and match Delphi versions like this. When you are ready to upgrade, do it in a coordinated and unified manner.

Try calling BringToFrontNoCap()

Hardly. It's possible, indeed common, for one person to be working on multiple branches

Use names. The performance issue you describe doesn't exist.

If the OP would explain the original motivation behind this, then we could propose proper solutions to the actual problem. This is a canonical XY question.

You can add to a counter when allocating new blocks, and decrement when deallocating, and then you find bleat if the counter is non-zero on exit

Rather than re-compile the RTL you can register a custom memory manager, which is very easy to do backed with MSHeap. And then you can add simple memory leaks on shutdown reporting. I actually do use the MS heap for my MM because I want to implement a per thread MM so that I can get decent performance on NUMA systems.

I'd definitely not be using Shortstring for that. But the asker has talked about the usage being for database. So RS232 not pertinent.

Same as always. Numerical programming. And when there exists huge amounts of code in a language, it can be hard to leave. A phenomenon well known to us Delphi programmers!

Different use cases will suit different libraries. You gave no indication of what your motivations and goals are.

Or when calling into a Delphi DLL.

That's Embarcadero's fault. They've known how to fix this for at least 10 years, and my patched version of the RTL fixes it. That said, the real issue isn't really a language issue. It's a platform issue. It all stems from the way floating point is implemented on x86 and x86-64 hardware.

Clearly the OP is using short string because the compiler says so. My question is to the OP. Why use short string?

Is there a reason to use shortstrings? It's 2024 now....

Does it even compile, and if so what does it mean?

What problem does this solve?

Delphi doesn't know that you want [] to be an array rather than a set. Because the language has been designed iteratively and there is ambiguity. Delphi literals are a bit of a mess. In any case are you sure that you want to use = with a reference type? That's reference identity and not value identity. You will need to test for Length(a)=0 or not Assigned(a) or a = nil

Top down memory allocation, which is what I presume this setting is, was how I found most pointer truncation bugs back in the day. It also broke just about every anti virus software that we tried, until I settled on the MS tool!

It's just that the reason isn't to do what you did

Please provide a link to this post and if it's wrong then we can correct it. Or perhaps you didn't interpret it correctly.