Stefan Glienke

The closing quotes dictate the alignment, lines inside the string thus cannot be more left than the closing quotes, the last line does not have a trailing line break, if you want a trailing line break, add an empty line

Why exactly? data is the PByte parameter that comes into that function and if ultimately not nil it gets passed to ConstructAttributes

People like Gor would call the majority of the Delphi RTL and alike "not an appropriate solution for writing scalable concurrent software" so we have to be a bit reasonable when putting this statement into context.

Given that PowerToys is on GitHub, I would say that "they" is the community and not only MS - see "Support ARM platform"

As one of the few lib devs that actually test their code on all supported Delphi versions I object - dproj files so often have incompatibilities in them. Yes, it is possible to have only multiple dproj files but only one dpk they refer to and put the libsuffix stuff into an inc file referencing that one on the dpr (have done that, works fine) but it is tedious. I rather copy the latest version when a new one comes out/is in beta. The more important thing imo is using forward-compatible defines in the code - it drives me mad whenever I compile some code in a newer version and it simply does not work because the code requires explicit defines because they are not done in a forward-compatible way.

If you are referring to TGUID specifically then I would assume that to be the case as that is basically what happens because it has operator overloading. To be more precise though because my previous comment might be misleading: - currently, we don't get any W1036 on using a field on some local record variable (see Test4) - we get a W1036 on local intrinsic non-managed type variables such as Integer (see Test1) - we *don't* get a W1036 on local intrinsic non-managed type variables such as Integer when they get passed by ref (see Test2) or a helper method is being called on them (see Test3) anywhere in the routine. type TIntHelper = record helper for Integer procedure Foo; end; procedure TIntHelper.Foo; begin end; procedure PassRef(var ref); begin end; procedure Test1; var i: Integer; begin if i = 0 then Writeln; end; procedure Test2; var i: Integer; begin if i = 0 then Writeln; PassRef(i); end; procedure Test3; var i: Integer; begin if i = 0 then Writeln; i.Foo; end; procedure Test4; var g: TGUID; begin if g.D1 = 0 then Writeln; end; end. My point is - yes I can craft some version of Test4 where something might happen with g that causes it to be initialized or not - but the point is: if I access any field on it *before* that it is a hundred percent certain that I am accessing an uninitialized field. Now in practice the compiler source code and its design might be in a state where doing this is hard to achieve but the point is: it's not impossible.

We already have the situation that calling any method on a record disables the warning - I did not mention disabling that behavior, did I? Also, don't you think a compiler could easily see if the access to a field happens before or after some method call? I explicitly stated that there would still be cases where a W1036 would be appropriate but would not be seen due to some reasons but in the places where it is hundred percent certain that the access is to an uninitialized field the compiler should raise it

The explanation was given by the pm and not some compiler dev fwiw and it is nonsense tbh. The compiler already knows if a record is managed or not because if its managed then it inserts code to call to System._InitializeRecord. Now the case can happen that you access some field on a record that is a managed record but that field is of a non managed type - these fields are not touched inside that routine. The compiler can still issue a W1036 when accessing a field on a record that is not managed - would there still be cases where a warning would be missing? Yes, but it would be better than it is currently.

Coroutines are not a dead end at all - in fact, there are more and more languages making them first-class citizens because you can write asynchronous code just like you would write sequentially. Google for "project loom" for example.

https://bitbucket.org/sglienke/spring4d/branch/feature/coroutines - the reasons it never made it into the main branch are what has been mentioned before and the fact that on POSIX I emulate them using a thread and an event (which is deadly slow) - still until anyone convinces me otherwise (by showing some actual working code!) this is the closest we get to some conveniently usable coroutines in Delphi.

How would changing the variable from ColorRef to TColor help? That will only change the location of the warning because RGB returns ColorRef (given this is the function from Winapi.Windows.pas).

I am not sure what y'all discussing here but the snippet that Tommi posted is about checking the first character before even calling strncmp (video at around 15:15). It's pretty obvious why that is faster - if the characters don't match you get rid of the function call. The algo does not need to restrict anything - the hashtable contains all keywords and the input is any string that occurs in the source code - if it's a keyword, it gets found, if it's not, then it won't be found, simple as that.

On 32bit the compiler keeps the value of the multiplication in the FPU to pass it to Round (which takes its parameter as Extended), on 64bit the precision of Extended is the same as Double. You get the same result on 32bit if you store the result of the multiplication into a double variable and then pass that one to round.

No, because there are no parameters on ReadChar. No, because even if you mean the string concat method (which is UStrCat3 that will be called here) you will see that if you call ReadChar a third time suddenly order is correct (which then calls UStrCatN) No, because even parameter passing order is undefined behavior in Delphi

Every time I see allocations for comparing strings I have to cry

Of course, the result will be as expected if you name the two functions differently, then it does not matter what order they are getting called - but when it's twice the same function which returns different results then the call order matters Here is the code to simulate the issue: var callNo: Integer; const PGM_Magic_Number = 'P5'; function ReadChar: Char; begin Inc(callNo); Result := PGM_Magic_Number[callNo]; end; procedure Test; var s: string; begin s := ReadChar + ReadChar; Writeln(s); end; begin Test; end;

We recently discussed this in https://quality.embarcadero.com/browse/RSP-18259 - even after reading the comment in System.pas I cannot imagine what the idea behind ReleaseExceptionObject was given that AcquireExceptionObject returns a reference and thus also passes ownership to the caller. Thus the parameterless ReleaseExceptionObject cannot work by design given that it does not have any parameter where you might pass the previous result of AcquireExceptionObject. Even the documentation tells that this routine is just there for backwards compatibility and should not be used (I would have marked it as deprecated long ago so people that might still have it in their code would remove it) https://docwiki.embarcadero.com/Libraries/Alexandria/en/System.ReleaseExceptionObject

This would not be of much use given that one can use include files or other means to control their compiler options. You want a way to preserve the effective options at a given location to restore precisely that state.

That "works" (i.e. you wont get a GPF) because typed consts are no real consts but rather read-only variables (as in you cannot directly assign to them regularly). But I am sure this will cause a memory leak - a static one but ReportMemoryLeaksOnShutdown should complain about it.

Actually, it's way simpler: function BuildDigits(_Digits: UInt16; _Invalids: UInt8): UInt16; begin _Digits := UInt16((_Digits - 2048) * 11); _Digits := (_Digits and $FFFC) or (_Invalids and $03); Result := Swap(_Digits); end; IIRC a smaller than register size unsigned ordinal type will not cause an overflow when it wraps around 0 so it's not necessary to turn it into a signed to avoid that. The CPU uses 32bit register math anyway. The UInt16 of the multiplication is necessary though.

Which you obviously didn't which is the raison d'être of this thread

And my point was that you cannot assign signed to unsigned and vice versa without potentially getting them.

Pretty much because the very first line already is subject to a range check error. Many people have not noticed many potential range check errors because range and overflow checks were disabled even in debug config and only after they finally changed that they occur in a lot of code that unknowingly implicitly converts between signed and unsigned.

And why exactly would it be a problem to subtract 2048 from 0 in a signed 16-bit integer?

If you don't need language swapping while the application is running then go with the const array using resourcestrings. I say so because the const array is initialized on startup with the localized values from the resourcestrings. If you change language later they will not change.