Stefan Glienke

The term for that is Cargo cult programming

Not really as you can turn off this warning with {$WARN NO_RETVAL OFF}

You can put attributes almost everywhere without any errors, that does not mean that they are planned to be supported in these places.

I add Generics.Collections to some uses, then ctrl+click on it, boom Anyhow this is not the issue here as Uwe said, even 500 million failed createfiles are not burning a CPU core but rather the HDD/SSD. How you can see what is burning your CPU was explained in the other thread.

Create a new vcl application. Add any third party unit (one that is not immediately found in the first entry in the library path) - thus not a Delphi RTL/VCL/... unit or a Delphi unit without its fully qualified name. Then compile. The more entries you have in the library path and the more entries in the project options in unit scope names the more entries will pop up in procmon because it tries every possible combination (I don't remember in which order)

Probably - as far as I can see on saturday Stéphane wrote about the fresh install and referred to the wrong registry key being accessed. Yesterday he wrote about a fresh VM installation - at that point he did not claim that Rio was not installed without third party components. And if you look into the file he talked about earlier in this thread you can see that it uses quite a lot of third party stuff (like TMS Aurelius).

@Stéphane Wierzbicki @Attila Kovacs You should learn what procmon is telling there - all these attempted createfile are results of checking if the file exists and all the directories are obviously directories in the library path as a result of installing several third party components. And due to the way Delphi handles library/search paths when compiling (iterating them looking for the requested file and trying them with any possible unit scope - that is why you see it trying Vcl.Shell.blabla there, because usually Vcl.Shell is one of the unit scopes being put into a VCL project) this is what you get - nothing unusual there.

Yes, you can improve the compiler (the language) as much as that it is partially safe to access raw memory without copying it - google for: .NET Span<T> I did some experiments with it in Delphi and it improved some string parsing code that did not have to allocate new strings but also did not have to work with raw and rather unsafe PChar. See https://bitbucket.org/snippets/sglienke/7e6xoe/span - this however cannot do what the C# compiler can do with ref (ensure that it only lives on the stack to not lives longer than what it refers to and these things) plus C# has readonly ref - basically a readonly pointer.

Probably not for Delphi because there is virtually no market but you would be surprised what static code analysis can do.

Simple, one that knows that you are pointing to an array element and sees that you are resizing the array thus invalidating this pointer.

No

No, unless you reference the helper type itself somewhere which you typically don't and if you do you can just register the function somewhere so you don't need to use RTTI.

No, consts are consts and no types (even if nested in types) hence no RTTI Whatever you are trying you are probably better using something like DelphiAST and include that into your build process to generate something from source.

@Emil Mustea You could be that clever however the real runtime overhead of the spring smart pointer is so small that any such tricks are not necessary imo and rather lead to defects because of implicit variables as shown earlier. @pyscripter YMMV but when I compile with release config the results are within 2% difference. Depending on order and CPU caching in that micro-benchmark they are even equal.

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.