Stefan Glienke

The question is this: do you want to get a wide adoption rate of something you've built or do you want to get two and a half coffees paid. As for how the console is done: Visual Studio Code simply communicates via stdin/stdout/stderr - see https://vscode.readthedocs.io/en/latest/editor/integrated-terminal/

Working on some better integration and result format that can be consumed by state of the art tooling such as https://github.com/danielpalme/ReportGenerator or https://github.com/marketplace/codecov but thats a side project that I don't spend much time on. Also still fighting some spurious crashes with DelphiCodeCoverage that result from it putting its breakpoints where it really should not (I suspect some incorrect debug information from the map file).

This issue is as old as generics are: https://quality.embarcadero.com/browse/RSP-10506

If your experiments are not just for educational purposes try out Spring - the container can do exactly that.

IMO the only true way to do this in pascal is as they done in Oxygene - see "if expressions": https://docs.elementscompiler.com/Oxygene/Delphi/NewFeatures/

I don't know what you mean 😇

Not quite - this is the null coalescing operator ?: is a special version of the conditional operator - it is short for "if <expr> is not null then give <expr> else give <something_else>" Null propagation operator ?. is a special member access operator - short for "if <expr> is not null then access <expr>.<some_member> else do nothing or return null" Given that Delphi does not have a conditional operator I would assume that even though we might get language support for nullable types (reference types fall into that category) we don't get the null coalescing operator but chances are that we get a null propagation operator - but that is just me assuming things.

You are most likely referring to the null propagation operator because there are plenty of nullable type implementations around.

If you are a seasoned Delphi developer you know that new features are not usable for like half a decade or so...

Code that originated in a Version before 2009

If you have a bad compiler that puts cold code into the middle of your hot loop where performance really matters instead of restructuring the code you need goto.

And you indeed refactored it into the only sane form I can think of! Might have moved the Result := False into that final else though because it's only needed then. And could have replaced the softcast with a hardcast because you already did the is check.

Certainly but that would change the behavior - currently if the class is found it exits, regardless. With a giant if and/or statement it would continue to evaluate the is checks.

We know they never do that but rather hope they be ready when they ship which also as we know it not the case either.

Here are some more: Wrong codegen: https://quality.embarcadero.com/browse/RSP-34539 Bogus error: https://quality.embarcadero.com/browse/RSP-34540 Bogus operator calls: https://quality.embarcadero.com/browse/RSP-34541

Apart from the names of the labels its actually not that terrible tbh - certainly better than repeating the same code over and over in every check.

Here is some code that I recently wrote that looks stupid but indeed is clever because the compiler is stupid: if P = nil then Exit(Boolean(P)); P is of type Pointer and it ensured that it's in the same register that the result is being returned so in case it's nil there is nothing to do (if you would write Exit(False) the compiler would insert extra instruction to actually make the register zero (which it already is)

No, it's just shorter than writing: var LKeepProcessing: Boolean; begin repeat LKeepProcessing := ProcessMessage(Msg); until not LKeepProcessing; end;

Wrong

Unless you do that in place with PChar pointer magic that's a heap allocation! 😉

function MyStrToFloat(const S: string): Extended; const Komma: TFormatSettings = (DecimalSeparator: ','); Dot: TFormatSettings = (DecimalSeparator: '.'); begin if not TryStrToFloat(S, Result, Komma) then Result := StrToFloat(S, Dot); end;

Enable debug info - should not change the addresses if the code and all other options are exactly the same.

Whenever you stop at some breakpoint you can use it, make sure to prepend $ when typing the address because hexadecimal

I would approach this in a use-case driven fashion. If users want to migrate their existing code to Linux and have some issues because certain things don't compile then address those pieces until it works. This might require a little more lightweight approach of the library itself - I personally have never used JCL without at some point having run the installer that produced everything for me. I remember one time where I simply wanted to use one single unit from the JCL and it ended up pulling everything and the kitchen sink (including some inc files that were not there simply because the installer hadn't generated them)

Version3 is the best because its maintainable and gives compile error if anyone decides to add a new value - while cases don't and at best depending on the Compiler Version might give a warning about a non handled case. Also the benchmark is pointless because like 90% of the workload you test is string assignments - here is a screenshot from samplingprofiler: If you care for speed then get rid of the unnecessary function call. Unfortunately also depending on compiler version the inlining is not an option and rather makes things worse for functions returning managed types such as string You might be better by just directly indexing into the const string array.