David Heffernan

Can you show the code?

The RTL and spring4d are actually pretty comparable. Your claim that spring4d code should only raise a single exception class indicates that you don't appreciate its scope. Im an advocate for understanding something before judging it.

Ask yourself why the RTL raises more than a single class of exception.

Andreas is presumably doing other things these days.

Casting to a helper should never be supported. That's just ugly. May as well call a function and be done with it. You lose all the benefit of type extension if you have to cast.

The decision to implement the collections as records look problematic to me. That means these types will have value type semantics.

Inheritance would not be the ideal solution. That would make it impossible for two distinct libraries to extend the same type. I don't understand what is hard about having multiple helpers active and searching through them, most recently declared first.

We all think that ...... C# extension methods allow types to be extended from multiple classes .....

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.