Stefan Glienke

@Clément Did you actually read the very first post where it said: So the question is about the best data structure or algorithm to delete those items from the list and I am very sure the algo TList<T>.Pack uses is the most suited one. It is one iteration with batch moving remaining items to the front. The most impactful thing here will probably be calling the delegate to determine if the object should be removed and the dereferencing of the object reference to read some field that holds the information to give that information.

Then you are doing something wrong - can't repro {$APPTYPE CONSOLE} uses Spring.Container; type TModifyingSQLKind = (SQLInsert); TSQLDataSuiteWorkerMethod = procedure of object; ISQLDataSuite = interface ['{068D3552-CBA6-4AAE-9061-59FA6407FF8C}'] end; TSQLDataSuite = class(TInterfacedObject, ISQLDataSuite) public constructor Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean); overload; constructor Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean = True; const aBeforeWorkerMethod: TSQLDataSuiteWorkerMethod = nil; const aAfterWorkerMethod: TSQLDataSuiteWorkerMethod = nil); overload; end; ISQLDataSuiteFactory = interface(IInvokable) ['{A101FA06-ED33-478A-9066-821BC8C5E2AE}'] function Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean ): ISQLDataSuite; overload; function Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL : Boolean; const aBeforeWorkerMethod: TSQLDataSuiteWorkerMethod; const aAfterWorkerMethod: TSQLDataSuiteWorkerMethod): ISQLDataSuite; overload; end; { TSQLDataSuite } constructor TSQLDataSuite.Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL: Boolean); begin Writeln('create'); end; constructor TSQLDataSuite.Create(const aTableName: RawByteString; const aSQLKind: TModifyingSQLKind; const aProcessSQL: Boolean; const aBeforeWorkerMethod, aAfterWorkerMethod: TSQLDataSuiteWorkerMethod); begin end; var fSQLDataSuiteFactory: ISQLDataSuiteFactory; begin globalContainer.RegisterType<TSQLDataSuite>.Implements<ISQLDataSuite>; globalContainer.RegisterFactory<ISQLDataSuiteFactory>(); globalContainer.Build; fSQLDataSuiteFactory := globalContainer.Resolve<ISQLDataSuiteFactory>(); fSQLDataSuiteFactory.Create('TableName', TModifyingSQLKind.SQLInsert, True); Readln; end.

Leave the pub once you reach the Ballmer Peak and then work on your program to make it even better

Of course but I am assuming that Steve is doing more with this list than just removing many items at once. My personal experience with collections and a lot of material I read and watched is telling me that the chances are kinda slim that a linked list will perform better in the overall usecase. Anyhow in the context of this question any discussion of this is moot and my first sentence in my first comment still stands. Anything else is a waste of time.

Ask google and read up on prefetchers and cache locality.

When looking for the correct constructor to match the algo tries to match the parameters given with the parameters required by the constructor. However it does not allow injecting nil which is the reason it does not consider this constructor. As for a subforum - there is already a forum for Spring4D at https://groups.google.com/forum/#!forum/spring4d

RemoveAll is the way to go - it is optimized internally for lists (at least since 2.0/develop) - not yet for dictionaries but there it more depends on what is the criteria for deleting items as remove by key is already O(1) The approach with Where/Remove does not work because the result of Where is lazy evaluated and will raise an exception once the source gets modified (after the first deleted item). Even when calling ToArray to manifest the collection of to removed items the Remove will be a waste of time because items would be searched all over.

Measure, don't guess - basic rule of performance tuning Linked list is a bad idea btw - if anyone thinks otherwise he needs to get an update on modern CPU architectures.

GetKeyState and related WinAPI functions are broken with Numlock enabled - and you are not the only one suffering from this defect if you google for numpad shift stuck If you release the shift key first it never sees the keyup of the insert key (which the shift key turned the numpad 0 key to). You have to use other ways to do that

Use diff tool/setting that also shows whitespace/eol differences

If there are no generics it's a different issue than RSP-27000.

The reason is they added a converter for encoding fields in TStrings to Data.DBXJSONReflect so it writes it different from before.

I just tested it and reduced the code further to pinpoint the wrong behavior, added additional information and reported as RSP-27000

Emba does not contribute to open source - especially not GPL

The TypeInfo uses the value $80000000 to indicate that this property has no default value. That unfortunately overlaps with Low(Integer). You have to use the stored keyword: property MinValue: Integer read FMinValue write SetMinValue stored IsMinValueStored; function TMyComponent.IsMinValueStored: Boolean; begin Result := FMinValue <> Low(Integer) end;

Because!

The point is that DestroyWnd is never called on the TForm (tested with 10.3) thus FDropTarget never destroyed.

It ever did? Not for code that I write and it does not completely format as I would like it to.

Nah, in fact I only use a fraction of what GExperts offers, I just cba to disable those that I don't need.

Use LeakCheck - there is even a blog post how to. Not having done anything on something that just works does not mean abandoned. If something does not work, let him know. FastMM is good to report memory leaks on an entire application run but not suited for unit tests memleak reporting - that is why LeakCheck was written plus having something that works cross platform.

Although I am a big fan of rtti and attributes I would choose the const array[enum] of x any day as its compact to write and compile time evaluated (i.e. error if someone introduces a new enum value and forgets to specify an array value for it).

Check the $RTTI directive in System.pas ... - also there is no this or that RTTI. Stuff from Rtti.pas just puts an easier to use layer ontop of the pointer stuff from typInfo.pas

Well, not if the method is private or protected

Yes, and I never stated otherwise - I just pointed out that you can patch virtual methods selectively by replacing them in the VMT. inherited calls would also still call into the old method with that approach. FWIW the approach you wrote for private virtual method works as well for a non virtual method. In fact the technique of hooking methods by placing a jmp has nothing to do with how the methods are being called. Especially for patching known code (i.e. RTL and alike) I rather write byte scanning code for finding the place I want to patch - yes such code has to be changed when you migrate to another version. But with that you can patch any code even if it's hidden deep within the private section of some classes or in the implementation part of a unit.