Stefan Glienke

That would have caused a ton of unnecessary extra initializations because of out param. If the compiler would actually be clever and detect them and omit when unnecessary I would agree. Also if it would not be that terrible it could actually give the warning regardless the internal working of the parameter.

The ISafeGuard approach is not a smartpointer but creating a scope to some resource. There is a important difference: a smart pointer combines the resource and its lifetime management into one entity. Also the record based approach is the most naive one - while Spring4D offers this one as well it has a more advanced one. As for performance: measure it yourself: program MeasureIt; {$APPTYPE CONSOLE} uses Spring, Diagnostics, Classes, SysUtils, JclSysUtils; const ADD_COUNT = 10; CREATE_COUNT = 100000; procedure MeasureSpring; var s: IShared<TStringList>; i: Integer; begin s := Shared.Make(TStringList.Create); for i := 1 to ADD_COUNT do s.Add(i.ToString); end; procedure MeasureJcl; var s: TStringList; g: ISafeGuard; i: Integer; begin s := TStringList.Create; Guard(s, g); for i := 1 to ADD_COUNT do s.Add(i.ToString); end; procedure MeasureClassic; var s: TStringList; i: Integer; begin s := TStringList.Create; try for i := 1 to ADD_COUNT do s.Add(i.ToString); finally s.Free; end; end; procedure Main; var sw: TStopwatch; i: Integer; begin sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureSpring; Writeln(sw.ElapsedMilliseconds); sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureJcl; Writeln(sw.ElapsedMilliseconds); sw := TStopwatch.StartNew; for i := 1 to CREATE_COUNT do MeasureClassic; Writeln(sw.ElapsedMilliseconds); end; begin Main; Readln; end. The implementation in Spring 1.2.2 (currently released version) uses very optimized code for the smart pointer itself avoiding the overhead of an object allocation and all the code associated with it but only allocates a 12 Byte (32bit) block with the IMT. Since IShared<T> is not a regular interface but an anonymous method you can directly access the members of the underlying type. Yes, there is a method call every time but as you can measure that does not cause any significant overhead (unless you call .Add a million times). And even then the actual work being performed totally outweighs the smart pointer overhead

*facepalm*

The patches that went in 10.3 are mostly IDE related and not compiler related afaik. Also from a few comments about the progress dialog alone affecting the duration of the compilation I have the strange feeling that inside the IDE the progress callback is wired a bit wrong (synchronous instead of asynchronous) causing unnecessary extra slowdown.

You, the container only is responsible for singleton lifetime

If possible - often enough you ifdef because of bugs or workarounds. I usually ifdef using the defines from jedi.inc and put a comment to the reported issue that I ifdef for.

Your question shows your lack of knowledge on the topic (I don't mean that in any form negative) so I suggest you should not mess with it. RTTI is queried with code that executes at runtime and thus can only cause errors at runtime. And even if you in your code don't explicitly make use of RTTI that does not mean that any other part might not do it (either third party or even RTL). Want to serialize some object to JSON and use System.Json - ohh, will not work if you did disable RTTI (just one example). So unless you really have a problem because of binary size (and no, we are most likely not in a 64k demo scene competition here) then apply the first rule of optimization by Michael A. Jackson: "Don't do it."

The R in RTTI is for runtime - now please guess 😉

Eye candy goes hand in hand with UX. If the usability sucks people will notice. If the UX is great but the UI is a bit dated people that are actually using it won't complain (much) but new users might pass by just because the first impression is not great visually. If all you got though is eye candy it might draw people but then let them down by crappy UX.

System.Diagnostics.TStopwatch

If _UStrArrayClr is giving you an AV I am putting all my money on passing something wrong somewhere and destroying it's reference counter causing a premature FreeMem or something similar.

It's easy enough to profile where the mass of heap allocations are coming from by using FastMM full debug and log the callstacks. Or run under SamplingProfiler and check what hits the memory routines most.

@Attila Kovacs Your quote from the help is kinda misleading because the code path there is the one handling the function not succeeding but returning ERROR_INSUFFICIENT_BUFFER. @Kryvich The help combined with the code below is confusing me. It says number of bytes but then it also does a dwSize/sizeof(WCHAR) to allocate a wchar array 😕

If you're interested, look there - otherwise too much noise for a forum imo.

https://quality.embarcadero.com/issues/?jql=affectedVersion %3D "10.3 Rio" and status not in (Closed%2CDone%2CResolved)

Yup, did that. To work around that issue, you can put list.List into the watches.

What exactly do you do, what you posted is a private method that obviously gets called from another public method. Please show your code.

@Arnaud Bouchez I know you like to deal with low level stuff but being able to be more declarative about loops and other language constructs is a benefit imo. That var passing of the loop variable is bad, but Primoz wrote that just for fun and advised not to use it. I guess every Delphi developer knows how a while or repeat loop works but I have seen enough off by one errors caused by counting the loop variable wrong, messing up the loop condition or other stuff which could just be eliminated if the language itself could treat it right without the need to put extra abstractions ontop that just make code slower. Another thing that just applies to 10.3 though is that only in a for loop you can inline declare the variable to only be valid in the loop scope and not outside.

Better than releasing something that is broken and makes all your code fail, amiright?

The joys of packages as a library author. Looks like commit ace9e54 only modified the 10.2 package. That commit removed the following files: MARS.Client.Messaging.Resource.pas MARS.Client.SubResource.JSON.pas MARS.Client.SubResource.pas MARS.Client.SubResource.Stream.pas Just remove them from the contains in the MARSClient.Core.dpk and you should be able to compile.

The second parameter of the Assign operator actually has to be either var or const [ref].

Wow they are still (happened on the old forums as well) leaking email addresses in the usernames as they seem to be generated from the email used on the old community page ...

I am sure using the type keyword after the equals sign was not part of the original pascal syntax and is only there to let the compiler produce a new typeinfo instead of it just being an alias that still points to the exact same type.

Agreed, type redeclaration is really not very helpful in many situations. - you still have implicit type compatibility no matter what - but helpers stop working