David Heffernan

Nope. This is an endeavour that is doomed to fail. You'd have to duplicate the implementation of the standard helper if you wanted to have access to its functionality as well as that in your own helper. It's been this way since helpers were added, and I have given up hoping that the issue will be addressed.

Would be nice to localise the disabling of overflow checks to just the hashing routines.

Sure. But there has never been a compiler bug where this particular language contract was not respected. You say that you have seen the compiler generate code which evaluates for loop ranges more than once. But that's incorrect. You have not seen that because no version of Delphi has ever had such a bug. My point is that it is poor advice, a canonical example of FUD. For sure it's worth knowing that while loops are different. Proficient Delphi programmers do know this, and are alive to this whenever they make choices of which loop to use.

You have not seen this. The classic for loop evaluates the loop ranges exactly once. This is contracted by the language. http://docwiki.embarcadero.com/RADStudio/Sydney/en/Declarations_and_Statements_(Delphi)#For_Statements "For purposes of controlling the execution of the loop, the expressions initialValue and finalValue are evaluated only once, before the loop begins." This sort of FUD is not helpful to anybody.

There were two points in that post. The point about not using Length of the internal list is well made. But my post reacts to the other point in that post which advocated taking a copy of Count into a local variable before the for loop.

In for i := 0 to List.Count - 1 do Foo(I); List.Count is evaluated exactly once.

Websearch took me here https://en.m.wikipedia.org/wiki/Static_application_security_testing https://docs.gitlab.com/ee/user/application_security/sast/ https://github.blog/changelog/2020-05-06-github-advanced-security-code-scanning-now-available-in-limited-public-beta/

That's exactly the sort of analysis that you should be doing rather than blanket use of direct access of the internals.

I think OP's takeaway was to use direct array access always. I'd say use it with specific intent only. I'm dead against TList exposing its internal implementation details like that. Anyway, the Delphi collection classes have been such a mess over the years with so many bugs I gave up on them a long time ago and use my own collection library. If you can't do that then it's hard to see past spring's collections.

Which is why accessing via Items is to be preferred unless there are very well understood extenuating circumstances, for instance, measurable and significant performance gains. But in such a case I'd probably look to use a different collection.

Your interposer is effectively useless. When you call CardPanel.AddNewCard an instance of Vcl.WinXPanels.TCard is returned. No amount of casting can change that. You are just telling a big fat lie to the compiler. If you use as to cast then you will find out the runtime truth. They issue here is that you are trying to change the instantiated type of the cards. But declaring a new type of card doesn't achieve that since that code lives in the panel class. It's therefore the behaviour of the panel class that you need to modify. In order to get your card types created you should override GetCardClass. http://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.WinXPanels.TCustomCardPanel.GetCardClass You could do that with an interposer for TCardPanel. However, I wonder if perhaps the right thing to do is to stop using GUI controls to store data. GUI controls present data. They should not have knowledge of that data. Code outside of the control should be in charge of that.

Er, I mean the compiler option. You just switch it on and it finds defects in your code.

Nobody ever sets out to access out of bounds. But it happens. It doesn't happen because you decided to have a go at accessing out of bounds in case you get away with it. It happens because it's a mistake. The point of range checking is to detect those programming errors before the user is exposed to them. Presumably you use range checking?

Probably a bad idea. I would only do this in specific instances where you have timed your program and identified a bottleneck.

Wrong. The answer to my question is yes. SubItems: TList<TSubItem> When you access the items, a function getter is called, and that's where the copy comes from. That function getter has to assign its result somewhere and the compiler makes a temporary local variable for it. Hence the record init etc. Access the array directly and there will be no copy. aItem.SubItems.List[i] The const arg works as you expect.

Does aItem.SubItems[i] access an array directly, or is it a property getter with a function for the getter. The latter means a copy and would explain the behaviour. And if so nothing to do with the const arg.

It kinda makes no sense then that you also say that the data is ASCII (0..127). I'm very confused.

Just so long as VS Code doesn't auto uninstall every fortnight like it does with me......

At the start of this thread you said that the data was binary. Now you say it is ASCII. Hard to give advice on this basis.

Would be perverse to use 16 bit Char to store 8 bit data. In terms of performance byte strings and byte arrays are similar but if anything byte arrays will be faster. Precisely because they don't have coy on write. No idea why you thing strings perform better. My guess is that your antipathy to byte arrays is a hangover from the legacy Delphi anti pattern that byte arrays are handled as strings.

Flashing can be quite visually aggressive. It is often preferable to highlight a control in some other way.

In the long run it will be less efficient to continue using these bridges.

I can't understand why you would. Aren't you likely just to end up changing your code for no reason, given that the defect is almost certainly not in your compression library?

It's pretty bad advice. Changing algorithm and implementation without any justification or rationale. Seems like you are advocating trying libraries at random. If every time you encounter an issue you replace the lirbsry, after a while you'll have run out of libraries.

They are. That's the a very plausible explanation. File corruption is something that does happen. You'll want to reproduce the issue before trying to solve the problem. And if it is file corruption then the solution is somebody else's problem.