Anders Melander

Fair enough. I've come to use them a lot. Often I have to remind myself to use a new feature after it's introduced but this one feels so natural that I'm not thinking about it all. If anything I have to remind myself not to use it too much. The ternary operator. Didn't like it when my main language was C++ and I still don't like it. For me it somehow breaks the flow when I'm reading code.

Why so sad? Because of the leak?

I would examine the call to Save in the CPU view in the debugger to determine when, and if, the passed variant is cleared. I remember there was some leakage issues surrounding variants passed as value parameters to dispatch interfaces but I can't remember the details anymore. Not related to your leak but: Instead of String(AInputVariant) you could do: VarToStr(AInputVariant) Instead of copying the TStringStream to a TMemoryStream, why don't you just operate directly on the TStringStream? lStringStream.Position := 0; lOutputStream.CopyFrom(lStringStream, lStringStream.Size); is the same as lOutputStream.CopyFrom(lStringStream, 0);

If you could define what "some json issue" is then we (and you) would have a chance of actually solving this problem. Right now we're all just guessing.

Yeah, there's that. My point was more that the Delphi does much more. Not that it wouldn't be nice if they made it more or better "pluggable".

So, you do a lot of GUI design, debugging and building in VSCode?

Remember that we're talking about UCS4StringToWideString and not WideStringToUCS4String but I'll try again: Yes, it's a given that the resulting string, which is a 2 byte widestring, will be zero terminated as all Delphi long strings are. If the input was a PUCS4Char (a pointer to a zero terminated 4 byte string) then the input would have to be zero terminated. But it isn't. The input is an array in which the length is implicit. This means that the zero termination requirement is superfluous. The function could be implemented so that it handled both arrays with and arrays without a zero in the final entry. You know; Defensive coding. Just in case someone mistakenly passed an array that wasn't zero terminated because the documentation didn't state that you had to...

Okay. Yes, I can see that there's a git merge --squash command. So I guess SourceTree squashes commits by default because when I merge and push I only get one new commit in the history of the target. The only reference to "squash" that I've come across in SourceTree is in the Interactive Rebase dialog (which I don't understand enough to dare use).

I meant the function doesn't need it to be zero terminated (it has the length already).

So how do you deal with mapped drives, mounted volumes, symbolic links, junctions and hard links?

Squash? But that's a rebase thing, right? So how can you squash without rebase? Anyway. Let's say I have my 'master' commit history: 1. Initial commit 2. Made some changes 3. Fixed some changes At commit #2 I branch 'master' into 'FooBar' and make "a few" commits to that branch: 1. Experimental stuff 2. Enhancements ... 999. Refactorings 1000. Updated easter egg Now I merge my 1000 commit branch into master (resolve conflicts etc): 4. Merge branch 'FooBar' into 'master' And push. So the now 'master' commit history will read: 1. Initial commit 2. Made some changes 3. Fixed some changes 4. Merge branch 'FooBar' into 'master' Are you saying that you'd want the whole 1000 'FooBar' commits to appear in the 'master' commit history? I can see that if you don't have 'FooBar' pushed to the remote then the history will be lost, in which case it makes sense, but if you have pushed it, then there's no need to duplicate that history in 'master'.

You didn't answer any of the questions.

I'm not sure I agree with it. As I read it, and I may well be misunderstanding it, it assumes that when I merge my 1000 commit feature branch into master that I want all 1000 commits to appear in the master commit history. Well I definitely don't. The 1000 commits are the sausages being made and I only want the finished sausage in the master commit history. There's also this: What it should have said is: never rebase a public branch. It's perfectly safe and normal to rebase a private branch on a public branch. Assuming on=onto. Maybe that's what he meant.

Well I meant without opening the file. Of course Windows itself is able to determine if two local files are the same. If opening the file is OK then, yes GetFileInformationByHandle will get the job done. There are also other API functions that can be used if opening the file is okay. For example the undocumented NtQueryObject API can be used to get the logical filename of just about anything (e.g. C:\Windows -> \Device\HarddiskVolume1\Windows). The PIDL solution definitely won't work. PIDLs live in the shell namespace and you need to go much lower than that to determine identity.

There's no need to state the obvious. While the function may behave as designed, it's at the very least poorly documented. I looked at both the documentation and the implementation before I came to the conclusion that there was a bug. I'm fine with the implementation staying the way it is (to avoid breaking existing code) but it should be documented that the array is assumed to be zero terminated. Actually since the array doesn't need to be zero terminated (we know the length of the "string" already from the array) I can't see why the zero termination couldn't be made optional. Either way: fix the documentation.

Ah. I didn't check the source. I just assumed the documentation was correct. Silly me

\\?\UNC\ isn't an extension of \\?\ https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces This means that if the path starts with \\?\ then what ever follows is beyond what ExtractFileDrive was meant to handle. It could attempt to just strip the \\?\ part and retry but it I think it would be reasonable to give up and just return an empty string. Good luck with that. It isn't even possible to determine if two fully qualified paths refer to the same file.

Yes but each element is an UCS4Char (which is 4 bytes), so the string (it's an array actually) size is 9 * SizeOf(UCS4Char).

Yes it does: function UCS4StringToWideString(const S: UCS4String): _WideStr; var I: Integer; CharCount: Integer; begin SetLength(Result, Length(S) * 2 - 1); //Maximum possible number of characters CharCount := 0; I := 0; while I < Length(S) - 1 do begin if S[I] >= $10000 then begin Inc(CharCount); Result[CharCount] := WideChar((((S[I] - $00010000) shr 10) and $000003FF) or $D800); Inc(CharCount); Result[CharCount] := WideChar(((S[I] - $00010000) and $000003FF)or $DC00); end else begin Inc(CharCount); Result[CharCount] := WideChar(S[I]); end; Inc(I); end; SetLength(Result, CharCount); end; The bug is the Length(s)-1 in the while condition (or the < instead of <=). The first SetLength also seems strange. And can't see why it should do a -1 there.

No. Seems like it's gone. Strange.

One could argue that it's equally meaningless to use ExtractFileDrive on that path since whatever comes after the "\\?\" is handled directly by the file system and not by the file namespace parser. I guess the correct thing to do would be to return an empty string as documented: I do not agree with your suggestion that it should attempt to extract anything if the string starts with "\\?\" (or \\.\ for that matter). The result would be meaningless in the context.

I'd say that if you have records that size then the iterator is not the problem you should be focusing on

I think you might be confusing UTF-8 and Unicode because your example is using unicode strings and not UTF-8 strings. If what you have is in fact unicode and you just want to remove non-printable characters then you can use the TCharacter class: for var i := Length(s)-1 downto 1 do if (not TCharacter.IsValid(s[i])) or (TCharacter.IsControl(s[i])) then Delete(s, i, 1);

Why would calculating a pointer cause a cache miss?

Sure. For personal projects I rarely use branches at all. It's only when I start on something that I'm not sure I will end up using in the end (e.g. experiments) or some feature that will take so long to implement that I don't want it interfering with whatever else I'm working on) that I use branches. But even for personal projects it's good to be able to go back in time to find out what what you did that broke something. Sometime you can even use the commit message to clear up why some piece of code is there in case you forgot to document it properly with comments in the code. You could say that the individual code comments document the tactic while the commit message document the strategy. Of course it would be best if the code comments did both but we're not all super humans.