Stefan Glienke

No, they are not - apart from alignment as David pointed out it depends on the data type - string, interface or dynamic array assignments for example are far from being atomic.

Using a CS for many-read-few-write scenarios might be slow but only you can know and measure.

Version 1.0.1 now properly identifies as monospace.

In C# there is no Nullable<T> where T is a reference type (because the declaration is like this: public struct Nullable<T> where T : struct) unless you are using C# 8 and have enabled nullable reference types - and then there still is no Nullable<T> for any T that is not a struct but the compiler prevents null in a reference type unless you specify it as nullable. I am pretty much sure that if we ever get nullables in Delphi they don't implement such a feature as C# 8 does to prevent null/nil in reference types.

Sure, write your own compiler

It's a "magic" function implemented by the compiler without code in System.pas

It doesn't matter - they all look terrible in the Delphi IDE on High DPI

I was not talking about making classes for UI controls but exposing your dataobjects in a way that you can bind them in some way to the UI. Personally I don't like LiveBindings that much - and I gave up on some MVVM-ish approach for Delphi. What works kinda well is going the DB aware approach with datasets (can use things like the TObjectDataSet from Spring4D or other similar ones - DevArt for example has also one) that just are adapters to non dataset/database data such as lists of objects. There are other approaches such as my TTreeViewPresenter that connects an IObjectList from Spring4D to a TVirtualStringTree to display and even edit data.

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem. Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

I think so but I would rather consult the Windows documentation on roaming profiles to be sure.

The refCount is -1 because its a reference to a string literal - UStrClr being called because passing to out does not deallocate but still put nil into the passed variable. And fwiw the empty string also happens for WideString because then WStrClr is being called before passing as out. And while we are at it - yes AnsiString as well - LStrClr in that case.

There is no C:\Users\Public\Public Documents - that's just how they get displayed in the explorer - click into the address bar and you see its C:\Users\Public\Documents (by default - it can be anywhere else) Is the file ... for the program itself and ... only on this machine and for every user -> %programdata%\<program name> only on this machine and only for current user -> %localappdata%\<program name> available on other machines for the current user -> %appdata%\<program name> some document/file for the current user only -> %userprofile%\documents something that should be available for other users on this machine as well -> public documents (I think there is no variable by default for that, only for the public folder, but the public documents can actually stored somewhere else, I think registry holds that information)

There is no RTTI available for interface properties - you have to refer to them via the setter method name. And even that only works if the interface has {$M+} or inherits from IInvokable.

Sounds like an idea for a new rule to add for FixInsight and alike

https://www.idefixpack.de/blog/ide-tools/ide-fix-pack/ and https://www.idefixpack.de/blog/downloads/ both say "10.3 (RTM/UP1/2/3)"

That code would not even compile as the two New overloads in TBase don't differ from each other parameter wise.

If an object implements many interfaces it handles many responsibilities and not only a single one (SRP). You can use aggregation and delegation of those interfaces.

Look into TActivatorContainerExtension

Write your own ConstructorSelector that does not want the one with the most parameters.

@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