Delphi-PRAXiS - NatCompare

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - NatCompare (https://www.delphipraxis.net/170542-natcompare.html)

Vor kurzem wurde ich durch den Beitrag

http://www.delphipraxis.net/1181723-post35.html und insbesondere durch den Kommentar

Zitat:

Zitat von XxnemesisxX49 (Beitrag 1181723)

Juhu, es klappt, ich könnte tanzen...

auf die diesem Beitrag

http://www.delphipraxis.net/1181699-post21.html angehängte "NatCompare.pas" aufmerksam.

Leider kann ich XxnemesisxX49s Begeisterung überhaupt nicht teilen, weil die Unit mehrere Fehler enthält.

Im Detail:

Wenn einer der zu vergleichenden Strings leer ist, kommt es vor, dass eine Exception "xxx ist kein Integerwert" auftritt.
Ursache :
In

Delphi-Quellcode:

			function GetNext(const S: String; var Start: Integer; var IsNumber: Boolean): String;
		

wird zwar erkannt, dass "nichts mehr da ist", was verglichen werden könnte, jedoch wird IsNumber nicht = false gesetzt, was in der aufrufenden Funktion NaturalCompareFunc dazu führen kann, dass versucht wird einen leeren String mit IntToStr in einen Integerwert umzuwandeln.
Abhilfe :
In GetText als erste Zeile IsNumber:=false; einfügen.

Wenn beide Strings an der gleichen Position Zahlen enthalten, und eine dieser Zahlen größer als maxint ist, wird ebenfalls eine Exception geworfen.
Abhilfe:
In der Funktion NaturalCompareFunc die Zeile
Result := StrToInt(P1) - StrToInt(P2)
ersetzen durch
result:=NumCompare(P1,P2)
Die weiter unten stehende NumCompare verarbeitet auch kilometerlange Zahlen.

Die in den Funktionen NaturalCompareStr und NaturalCompareText den Stringvergleichen nachgeschaltete Funktion IntSign ist fehlerhaft.

Delphi-Quellcode:

			function IntSign(x:integer):Integer;

begin

   if x > 0 then

      Result := 1

   else if x < 0 then

      Result := -1;

end;

Was passiert wohl, wenn x = 0 ist ?
Richtig, das Resultat ist undefiniert, zumindest unter XE2 wenn die Optimierung ausgeschaltet ist. Bei anderen Versionen mag das anders sein. Auf jeden Fall sollte man sich nicht darauf verlassen, dass auch bei zukünftigen Versionen das EAX-Register unverändert bleibt. Ein weiteres Argument ist, dass bei 64-Bit Versionen der Parameter "x" in RCX übergeben wird, das Resultat aber weiterhin in RAX erwartet wird. Fairerweise muss man aber zugestehen, dass diese Entwicklung bei Erstellung des Codes wohl nicht absehbar war.
Abhilfe :
Als erste Zeile
Result:=x;
einfügen.

Delphi-Quellcode:

			// Vergleicht die numerischen Werte zweier Strings.

// Achtung : Die aufrufende Funktion muss sicherstellen, dass S1 und S2 nicht leer sind

// und ausschließlich aus Zeichen "0".."9" besteht.  

FUNCTION NumCompare(const S1,S2:String):integer;

var n1,n2:integer;  p1,p2:PChar;

begin

   p1:=@s1[1];

   p2:=@s2[1];

   while p1^='0' do inc(p1);

   while p2^='0' do inc(p2);

   n1:=@s1[Length(s1)]-p1;

   n2:=@s2[Length(s2)]-p2;

   result:=n1-n2;

   if (result<>0) or (n1<0) and (n2<0) then exit;

   repeat

      result:=Ord(p1^)-Ord(p2^);

      inc(p1);

      inc(p2);

   until (result<>0) or (p1^=#0);

end;

Hab mir noch nicht alles durchgelesen, aber

Zitat:

Achtung : Die aufrufende Funktion muss sicherstellen, dass S1 und S2 nicht leer sind

warum machst du dann sowas wie

Delphi-Quellcode:

p1:=@s1[1];

Delphi-Quellcode:

p1:=PChar(s1);

= fertig und keine Probleme mehr, wenn man nun auch noch auf #0 prüft oder bei den Berechnungen für n1/n2 etwas aufpaßt. :roll:

Zitat:

n1:=PChar(s1)+(Length(s1)-1)-p1;

(ich hoff mal die -1 stimmt)

Zitat:

Zitat von himitsu (Beitrag 1183946)

warum machst du dann sowas wie

Delphi-Quellcode:

p1:=@s1[1];

Delphi-Quellcode:

p1:=PChar(s1);

Weiß ich eigentlich auch nicht so richtig, aber vermutlich aus dem gleichen Grund, aus dem du hier

http://www.delphipraxis.net/1183123-post17.html nach
if Pointer(s1) = Pointer(s2) then Exit(True);
schreibst:
if Pointer(s1) = nil then l1 := 0 else l1 := (PInteger(s1) - SizeOf(Integer))^;
if Pointer(s2) = nil then l2 := 0 else l2 := (PInteger(s2) - SizeOf(Integer))^;
besser wäre
if (Pointer(s1)=nil) or (Pointer(s2)=nil) then Exit(false);
l1 := (PInteger(s1) - SizeOf(Integer))^;
l2 := (PInteger(s2) - SizeOf(Integer))^;
Warum?!
Weil du eingangs bereits geprüft hast, dass nicht beide identisch sind, was einschließt, dass nicht beide nil sind.
Wenn du dann feststellst, dass einer der beiden nil ist …..

Zur Ausgangsfrage :
Einfach nicht richtig überlegt.
Danke für den Hinweis (das ist nicht ironisch gemeint).

Zwischenfrage: Ist "nil" identisch mit dem Zahlenwert "0"? Weil rein aus Pointer-Sicht kann ein Null-Pointer ja überall unterhalb der Base-Address liegen, und muss daher nicht zwangsweise "0" sein um "nil" zu sein. Wie sicher ist "nil == nil"?

Rein wertmäßig ist Beides absolut identisch:
Pointer(0) = nil
0 = NativeUInt(nil)

Aber Falsch. Nil liegt zwar unterhalb der Base-Adress, aber es kann nicht alles sein, was darunter liegt. :warn:
Erstmal gibt es mehrere Base-Adresse jenachdem was man als Base anzieht, hat jede DLL/EXE eine BASE (Startadresse) im Speicher und dann hat jeder bei Windows reservierter Speicherblock nochmal seine eigene BASE.

NIL ist aber immer "0".
Ja, früher haben ein paar Idioten Unwissende einfach

Delphi-Quellcode:

Integer(P) <= 0

verwendet, um "ungültige" Zeiger zu erkennen, aber nicht für NIL-Zeiger,
aber das geht natürlich nur bis zu einer Speichernutzung von unter 2 GB "gut".

Klar kann man hier und da noch ein bissl was optimieren, vorallem wenn man einfach mal blind ignoriert, daß es Idioten gibt, welche fahrlässig an der Speicherverwaltung rumspielen. (aber die gehören eh gevierteilt und erschossen und gehängt und dann noch gesteinigt)

Delphi-Quellcode:

			if Pointer(s1) = Pointer(s2) then Exit(True);

if Pointer(s1) = nil then Exit(False);

l1 := (PNativeUInt(s1) - 1)^;  // oder falls es keine Pointer-Arithmetik für diesen Pointer-Typ existieren

l2 := (PNativeUInt(s2) - 1)^;  // l2 := (PByte(s2) - SizeOf(NativeUInt))^;  // oder l2 := PAnsiChar(Pointer(s2)) - SizeOf...

// oder (aber hier legt Delpgi eventuell noch eine temporäre Vaiable für's Result auf den Stack, da nach Zuweisung

//   an das Result die Prozedur nicht sofort verlassen wird und je nach Optimierung könnte EAX belegt sein)

Result := Pointer(s1) = Pointer(s2);

if Result or (s1 = '') then Exit; // if Result or (Pointer(s1) = nil) then Exit;

l1 := (PNativeUInt(s1) - 1)^;

l2 := (PNativeUInt(s2) - 1)^;

Zitat:

Zitat von himitsu (Beitrag 1184023)

Delphi-Quellcode:

			if Pointer(s1) = Pointer(s2) then Exit(True);

if Pointer(s1) = nil then Exit(False);

l1 := (PNativeUInt(s1) - 1)^;  // oder falls es keine Pointer-Arithmetik für diesen Pointer-Typ existieren

l2 := (PNativeUInt(s2) - 1)^;  // l2 := (PByte(s2) - SizeOf(NativeUInt))^;  // oder l2 := PAnsiChar(Pointer(s2)) - SizeOf...

// oder (aber hier legt Delpgi eventuell noch eine temporäre Vaiable für's Result auf den Stack, da nach Zuweisung

//   an das Result die Prozedur nicht sofort verlassen wird und je nach Optimierung könnte EAX belegt sein)

Result := Pointer(s1) = Pointer(s2);

if Result or (s1 = '') then Exit; // if Result or (Pointer(s1) = nil) then Exit;

l1 := (PNativeUInt(s1) - 1)^;

l2 := (PNativeUInt(s2) - 1)^;

Und was passiert, wenn s2 nil ist ?
Ich denke, nur s1 auf nil zu prüfen, reicht nicht. Oder übersehe ich da etwas?

Stimmt, das passiert, wenn an wieder zu weit falschrum denkt.
Joar, s2 könnsollte man och noch prüfen.

Wenn s1=nil UND s2=nil wurde vorher abgefangen, also kann es danach nur noch unterschiedlich sein (und nicht gleich, wo man es weglassen hätte können) :oops:

Nja, was aber "theoretisch" niemals passieren kann, ist eine "Länge" von <= 0, denn bei sowas hat Borland es so definiert, daß der String dann intern NIL ist ... ist er nicht NIL (

Delphi-Quellcode:

), dann ist immer mindestens ein Zeichen darin. (außer jemand hat an der Speicherverwaltung rumgepfuscht)