Stefan Glienke

Especially for queues I don't see a clear advantage of a linked list even less so in favor of using an array. Even more for a circular buffer. I agree mostly with this answer. Also as for linked lists vs arrays - question knowledge that was aquired decades ago and refresh it considering modern hardware. Things like prefetchers make sequential data access order of magnitudes faster than random memory access resulting from non optimized linked list implementations.

To me that feature request makes little sense without actually pointing to a scan tool that handles Delphi/ObjectPascal as GitLab itself does not do that but just bridges to said external tool - see the second link in the previous comment. Edit: Ah ok, their approach is to build a generic scan engine - see https://gitlab.com/groups/gitlab-org/-/epics/3260 - would been kinda cool to provide some more information before asking to vote for something you have to gather information about on your own.

The issue here is not the list usage itself but using a list of records. I bet that the difference between the for in loop and the for to loop with accessing the underlying array would be almost zero if the items were objects.

I don't know - we are using self hosted GitLab - which only runs on Unix (see system requirements) and multiple Windows Server Virtual Machines that have Delphi, GitLab runner and much more installed. My guess though is their hosting just contains GitLab and not anything Windows.

Consider GitLab - while the hosting offer is probably similar their entire CI/DevOps stack is superior to what GitHub offers. Especially for using a language like Delphi where you cannot simply use some cloud service to compile stuff. (plus you can host GitLab entirely yourself should you want to in the future)

The code in TGotoModificationBaseExpert.HandleOnMenuPopup is causing an error every time I use Ctrl+# in 10.4.1 That is because there is an unconditional soft cast of _Sender to TPopupMenu which is not true all the time. Adding if _Sender is TPopupMenu around it fixes it.

I am still failing to understand how banishing with from the language would help refactoring code that uses it. Don't get me wrong - I am no big fan of that thing either and very very rarely use it - but all the hate usually comes from the fact that it's been used in hard to maintain code. That code has been written already and needs to get fixed. Yes, if it were not part of the language anymore at some point in the future code would not contain it anymore - but people that want to write bad code would still have plenty of opportunities to do so.

Hundreds of lines of code within one routine and you think that *with* is the problem? LOL

Pointer shifting over an array might only be faster because the array variable itself needs to be accessed again every time - this is mostly the case when the array itself is a field in a class and you are inside of a method. Accessing say FItems[LIndex] in a loop causes access to Self.FItems all the time. Simple storing @FItems[0] in a local variable and Inc that might be faster - but only because you then have avoided the array field access, not because pointer is faster than indexing into an array. Edit: even more so if you access that FItems[LIndex] multiple times - the compiler most of the time generates code to fetch FItems each and every time and does not treat it as if you stored it inside a temporary variable.

Fun fact: .net framework also is missing this in its String.Contains but .net core added an overload where you can pass an additional option how to compare. Let's remember back when TStringHelper was introduced into Delphi... yep that must have been around the time when .net did not have the overload yet (was introduced in core 2.1)

Nope - with classes you are dealing with reference types - in this case you are pointing to a location inside the dynamic array being used as storage inside the list - any reallocation can change that. True - however there is a difference between a language level feature and simply giving out some pointers to memory not directly under your control. ref return in C# for example has very strict rules to avoid running into any kind of problems.

Because the API now provides read by ref access which already makes it possible to changes values (which was the point) but also set by ref which does not store the ref but dereferences and assigns it. Also the regular Items property is now hidden and cannot be used. While it might be the easy solution it's not a good one in my book. In fact I think there is not even a good one unless language support. What prevents anyone from keeping around a reference that they retrieved from the Items property and then something in the list changes and boom.

Since the introduction of the Filter Exception expert I am often getting this error during debugging: You can easily reproduce this when causing some AV - for example by simply making a new console application and executing this code: PInteger(1234)^ := 42; Turn off the Filter Exceptions expert and this will properly show: I don't have any filters specified in the configuration of the expert.

And there the trouble starts - why on earth should the byref property be writeable.

You are simplifying things here - yes some collections such as list<T> can easily give ref access to its items but other collections might not. Working around the fact that you are dealing with value type semantics by accessing items by ref (or even giving raw access to the storage array such as the List property in the RTL TList<T> does) is borderline imo.

My number one argument for constraining on class in a generic type argument when possible is that you then can build most of the generic in a non generic layer and just put a small generic layer on top. That makes for less bloat.

All that I am using which would be mostly 10.1 and 10.4 - I would guess its related to the type of the exception - I usually see this with hardware exceptions such as AV or SO.

And that is why SRP goes down the drain, cyclomatic complexity increases, potential bugs increase, stuff gets broken - mostly in such swiss army knife classes. And what is complete - that differs for everyone.

Topic splitting can easily done by mods. Personally I would welcome if this was done more often so different things can continue being discussed in their own threads.

Correct, that's why you close the IDE before you switch the branch

If you are referring to switching between different versions of them I can only suggest putting those (yes the binaries, so dcu, dcp, bpl) into vcs - git lfs for example does a fine job.

I would never use interposer classes for that but simply run a one time search and replace for all occurences of the third party controls with my own.

Interposer classes are only good for components/controls that you already placed on forms because you can keep using them as is while you would need to replace a lets say TButton with TMyAwesomeButton. Where I also like to use them is for extending DUnit as I can use my unit with the TTestCase class then instead of the DUnit one and add functionality - but I would stay away from using it on RTL classes. Funny story: just yesterday we had a sudden compile error from a unit that was not touched in months. A class that was implementing an interface and the compiler complained about missing 2 method implementations. Turned out it was caused by the fact that a junior had added a TAction interposer class into a form unit. That unit was used in the unit which now failed - because those interface methods had TAction in their signature and now they did not match anymore.

Take a look at the screenshot you posted yourself...

Loading an entire file into a TStringList is a bad way to begin with tbh yet often the most easy way because there are no nice to use alternatives out of the box.