Stefan Glienke

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.

{$IFOPT R+}{$DEFINE RANGECHECKS_ON}{$R-}{$ENDIF} TempInt := TempInt * 11; {$IFDEF RANGECHECKS_ON}{$UNDEF RANGECHECKS_ON}{$R+}{$ENDIF}

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Procedural_Types_(Delphi)#Method_Pointers

Event types and TMethod while binary compatible (both consist of the data and code pointer) they are not assignment compatible. This routine will work for all event handlers that have the TNotifyEvent signature but not for others (such as mouse or key-related ones that have additional parameters). For those, you need to write overloads. procedure SetDefaultEventHandlerIfEventExists2(const AControl: TControl; const AEvent: string; const AHandler: TNotifyEvent); begin if IsPublishedProp(AControl, AEvent) then SetMethodProp(AControl, AEvent, TMethod(AHandler)); end;

I read "branchless" and I cry - see RSP-21955

Turn the strings into an enum or an index and put the functions into a const array over that enum/index.

Could the documentation be of any help?

No, it's not - it's the call from this line: https://github.com/microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1627 It however might look different today given that source on GitHub is from seven years ago but it might still give a clue. The weirdest way I got a "thank you" ever ngl

FWIW: https://github.com/microsoft/microsoft-pdb/blob/master/PDB/msf/msf.cpp#L1385

@Anders Melander Might be worth looking into https://github.com/llvm/llvm-project/blob/main/llvm/lib/DebugInfo/PDB/Native/PDBFileBuilder.cpp

This could be some relevant info: https://randomascii.wordpress.com/2023/03/08/when-debug-symbols-get-large/

Yes - because apparently according to the warning, there is a problem with "match the module with the symbol file". It could be very well a VTune bug though - after all the 2023.1.0 we currently get is a "pre-release".

I can't - as I confirmed the breaking change is from 2023.0.0 to 2023.1.0 and that explicit mention of large pdb file support was the most obvious clue. I don't know anything about the pdb format.

I just upgraded from 2023.0.0 where it worked to 2023.1.0 where it does not. What I noticed in the change log of VTune 2023.1.0 is this: Debug Support Support for Large PDB Files Starting with the 2023.1 version, on Windows* systems, you can resolve debug information from PDB files larger than 4GB. Could it be that the address bitness written by map2pdb is not correct now? In the collection log of VTune I can see this warning: Cannot locate debugging information for file `somepath\Tests.exe'. Cannot match the module with the symbol file `somepath\Tests.pdb'. Make sure to specify the correct path to the symbol file in the Binary/Symbol Search list of directories.

Personally, I would find it way more readable if you would not ifdef DELPHIAVX for every single line but simply make it two blocks, one using the avx instructions and one using db.

So you are saying that your app is already using more than 2GB (or more, large address aware and all that) and might not have enough space for allocating a simple string to store a file path in... But at the same time you are talking about using a form and showing information there... and where do you think the VCL (I am assuming you are using the VCL and not creating your form by directly accessing the winapi) takes its memory from? And worrying about the performance impact of try while scanning directories on the file system? Sorry, but this all makes absolutely no sense.

Wait what? Well first of a string is basically a pointer so you could store that inside of the pointer - nobody is talking about storing the string content into a pointer - you could only ever store 2 or 4 Unicode characters in there. So yes, of course, it's about storing the string index into the pointer.

Cannot be - if it's decremented by more than 1 then because the method was called more than once, simple as that. If the method is being called from multiple threads you need to use AtomicDecrement though. If you don't know from where the method is being called unexpectedly, use a data breakpoint on MyValue and the debugger will stop as soon as its being modified

If it's just a string variable you don't need to heap alloc anything - either use a const if you already know the exact content or use a preallocated buffer.

You could (ab)use the objects part of the first stringlist entries as index of the entry in the second stringlist 😏 To be more serious - while the dictionary is a fair approach it leads to duplicated data which can make updating data more complex. To find a good solution it might be worth it to explain a bit more about the data and the use case itself. You also mentioned a TStringGrid for UI which I personally find a terrible component.