David Heffernan

Good point. But I'm using XE7 and the string helper has many many bugs, including I believe in one of the split or join functions. Plus, my version minimise heap allocation.

I mean. I'd start by using TRegistry. And I'd write the code myself rather than hacking at scraps found from the web.

I'm sure you will be able to debug it. Good luck.

Best to be clear on what you are doing here. The code seems to assume ANSI. Again are you using ANSI text?

Once you get to the first double null then the rest of the data should be ignored. I'd remove everything after the first double null and then your original idea will work. You'll need to make sure you add back a double null terminator when you write it back. Are you really using ANSI text?

I doubt that what your posted in your original post really is a REG_MULTI_SZ. That really is double null terminated rather than null separated.

This is pretty flaky mind you. Sometimes type inference works, sometimes it doesn't and you have to be explicit. It is something that may have improved in more recent releases, but IIRC some issues remain.

I'm not sure what looking through assembly would tell you. If performance was your motivation then you'd time the code in a realistic setting, and if it was a hotspot then you'd do something about it.

That's a pretty unusual data representation. Double null-terminated strings are not uncommon on Windows at least. For what it is worth, you cannot call that null terminated, it is actually null separated. Personally, I would probably work with this sort of structure by converting to a string list and working on that internally. Then, at the interface between your code and the code that handles null separated data, convert it back to null separated. I use these methods to split and join: function Join(const Strings: array of string; Separator: Char): string; var Index: Integer; Len: Integer; Pos: Integer; begin if Length(Strings)=0 then begin Result := ''; Exit; end; Len := 0; for Index := 0 to High(Strings) do begin Inc(Len, Length(Strings[Index])); end; SetLength(Result, Len + High(Strings)); Pos := 1; for Index := 0 to High(Strings) do begin if Index>0 then begin Result[Pos] := Separator; Inc(Pos); end; Len := Length(Strings[Index]); Move(Pointer(Strings[Index])^, Result[Pos], Len*SizeOf(Char)); Inc(Pos, Len); end; end; function Split(const Str: string; Separator: Char): TArray<string>; var i, ItemIndex: Integer; len: Integer; SeparatorCount: Integer; Start: Integer; begin len := Length(Str); if len=0 then begin Result := nil; Exit; end; SeparatorCount := 0; for i := 1 to len do begin if Str[i]=Separator then begin Inc(SeparatorCount); end; end; SetLength(Result, SeparatorCount+1); ItemIndex := 0; Start := 1; for i := 1 to len do begin if Str[i]=Separator then begin Result[ItemIndex] := Copy(Str, Start, i-Start); Inc(ItemIndex); Start := i+1; end; end; Result[ItemIndex] := Copy(Str, Start, len-Start+1); end; Of course, you can work directly with the null separated strings. That will involve a function to find the index of the character at the start of the n-th item. Just loop through the string looking for the separator (null in your case). And then you can use Insert and Delete to modify the string.

That depends. I prefer to let the compiler choose whether or jot to inline. That seems to have better results than me doing it manually.

No. For static class methods it makes no difference whether its a class or a record.

Mine looks like this type Generic = class public class function IfThen<T>(Value: Boolean; const TrueResult, FalseResult: T): T; static; end; I don't think the name is that great, but my motivation was to use the same naming as the RTL. How I wish we could have generic functions outside of classes or records. Note that you should make this a static class method so that the class reference does not get passed.

This is what I was commenting on. Omitting parameters 2 and 3 makes no sense. There should not be default parameters for these functions.

Seems odd to replicate a function that already exists in the RTL. Also to implement it by potentially assigning the result variable twice. And the default parameters are very odd. It would never make any sense to omit these parameters.

A generic IfThen is trivial to write. I know I have one in my code base.

This is probably a mis-feature. I'd far rather such ambiguities resulted in errors unless you fully qualified the names. In fact it would be far better if units didn't have to be imported in full. If you could import classes, names paces etc. rather than having to pull an entire unit into the importing unit's namespace. Have you decided to reimplement other rtl functions, and if not why not? What is special about IfThen that you insist on reimplementing them?

The point is not that it doesn't behave as designed. It's that the design is poor. What is needed is a conditional operator built into the language, like in almost all other languages.

Well, now you've got to fully qualify function calls left right and centre, so it's hard to see this as a clean up.

That's a poor idea in my view.

This seems odd. Why would you need another implementation of IfThen for Integer and string? Why would you need more than one?

What types are the parameters for the functions that are ambiguous?

Not for every type. It's not helpful making these assumptions.

Sometimes reference types are best, and sometimes value types are best. That's why we have both. You cannot know that a class is right here.

You can't know that. It is easy to imagine scenarios where a value type is essential for performance reasons.

Use an open array parameter. http://rvelthuis.de/articles/articles-openarr.html