Alternative zu PosEx

[Amateurprofi]

Zitat von Sinspin:

Krass. Danke.

Sieht so aus als wenn ich malwider ein Buch in die Hand nehmen sollte und ein bisschen was zum Thema Assembler lesen. Ich fühle mich gerade irgendwie outdated.

Delphi-Quellcode:

{    Exceptions : Gibt an, in welchen Fällen Exceptions ausgelöst werden.      }
{                 0 = Keine, -1 = Alle                                         }
{                 In der aktuellen Version ist das Werfen von Exceptions       }
{                 deaktiviert, weil der Code hier nicht funktioniert.          }
{                 In anderen Anwendungen funktioniert er.                      }

Was meinst du damit? Fehlererkennung geht nicht oder Exception auswerfen geht nicht in 64Bit?

Ich meinte damit genau das was ich schrieb:
"Das Werfen von Exceptions ist deaktiviert."
Selbstverständlich werden Fehler erkannt, aber es wird auch dann keine Exception ausgelöst, wenn der Parameter "Exception" vorgibt, dass eine Exception ausgelöst werden soll, sondern ein entsprechender Fehlercode zurückgegeben.
Der Funktion gibt ja die Anzahl der Fundstellen zurück, die >= 0 ist.
Bei Fehlern ist das Ergebnis der Funktion negativ und kann sein:
-1 SearchFor (der zu suchende Text) ist leer.
-2 SearchIn (der zu durchsuchende Text) ist leer.
-3 SearchFor ist länger als SearchIn.
-4 Positions ist Nil (nicht assigned)
-5 Positions ist zu kurz, um alle Fundstellen zu speichern.
Zu -4 und -5
Es wäre natürlich eleganter, wenn die Länge von Positions innerhalb der Funktion gesetzt würde, aber das, was in Delphi nur ein simples "SetLength(Positions,M)" ist, scheint in Assembler nicht so trivial zu sein.
Na klar könnte ich das mit einer ausgelagerten Delphi-Prozedur lösen.
Auch das Werfen von Exceptions wäre mit einer ausgelagerten Delphi-Prozedur leicht zu machen.
Aber meine Philosophie ist halt, dass eine Assembler-Prozedur keine externen Subroutinen aufruft.

[Sinspin]

Nene :

Delphi-Quellcode:

{ 
Exceptions ...  deaktiviert, weil der Code hier nicht funktioniert. 
}

Ist aber eigentlich wurscht. Die meißten Exceptions enstehen eh durch unsaubere Programmierung. Sind also vermeidbar.
Ich arbeite aber eh lieber mit detaillierten Fehlercodes anstatt von Exceptions.

Setlength ist nicht trivial und sollte generell so selten wie möglich für das gleiche Array aufgerufen werden.
Verkettete Listen sind da deutlich praktischer. Kommen aber mit zusätzlichem Speicherverbrauch einher und sind beim kopieren hässlich.
Ich kann schon verstehen warum die Parameter sind wie sie sind.

[Stevie]

64bit StrPos ist defekt.

Teste selbst: StrPos('world', 'hello world', 0, 11) liefert 12 und nicht 7

[Blup]

Ich habe StrPosEx (32Bit) getestet und einen Fehler gefunden:

Code:

SetLength(Positions, 3)
StrPosEx('PaPa', 'PaPaPa', Positions)
Result = 1
Positions = [1,0,0]

Man muss das Array vor dem Aufruf auf die Anzahl der Ergebnisse anpassen.
Wenn der Platz nicht reicht, liefert die Funktion aber nicht die tatsächliche Anzahl zurück.
Die Fehlercodes sind für eine so simple Funktion eigentlich überflüssig, entweder es wird gefunden oder nicht.
Simple Überprüfungen kann man davor selbst vornehmen.

Meiner Meinung nach sollte die Funtktion den benötigten Platz selbst reservieren, z.B.:

Delphi-Quellcode:

function StrPosEx(const SearchFor, SearchIn: string; out Positions: TIntegerDynArray): Integer;
function StrPosEx(const SearchFor, SearchIn: string): TIntegerDynArray;

[Amateurprofi]

Zitat von Blup:

Ich habe StrPosEx (32Bit) getestet und einen Fehler gefunden:

Code:

SetLength(Positions, 3)
StrPosEx('PaPa', 'PaPaPa', Positions)
Result = 1
Positions = [1,0,0]

Man muss das Array vor dem Aufruf auf die Anzahl der Ergebnisse anpassen.
Wenn der Platz nicht reicht, liefert die Funktion aber nicht die tatsächliche Anzahl zurück.
Die Fehlercodes sind für eine so simple Funktion eigentlich überflüssig, entweder es wird gefunden oder nicht.
Simple Überprüfungen kann man davor selbst vornehmen.

Meiner Meinung nach sollte die Funtktion den benötigten Platz selbst reservieren, z.B.:

Delphi-Quellcode:

function StrPosEx(const SearchFor, SearchIn: string; out Positions: TIntegerDynArray): Integer;
function StrPosEx(const SearchFor, SearchIn: string): TIntegerDynArray;

Und wo ist da der Fehler?
"PaPa" wird in "PaPaPa" an Position 1 gefunden.
Dann wird geprüft, ob ab hinter der Fundstelle, also ab Position 1+Length("PaPa") der Text "PaPa" noch einmal gefunden wird.
Das ist nicht der Fall, also wird korrekt 1 zurückgegeben.

Zu "Meiner Meinung nach sollte die Funtktion den benötigten Platz selbst reservieren".
Hast Du einen Vorschlag, wie das zu realisieren ist?

[himitsu]

Zitat:

wie

Als VAR-Parameter und drinnen ein SetLength.


Per se ist OUT hier falsch, jedenfalls in Bezug auf Managed-Types, wie z.B. dynamische Arrays.
Zum Glück macht Delphi hier heimlich, und ohne was zu sagen, ein VAR daraus.

Bei OUT ist es möglich auch die Referenz zu ändern, was hier "eigentlich" zu einem Speicherleck führen würde, wenn vor dem Aufruf das Array einen Inhalt hätte.

[Amateurprofi]

Zitat von himitsu:

Zitat:

wie

Als VAR-Parameter und drinnen ein SetLength.


Per se ist OUT hier falsch, jedenfalls in Bezug auf Managed-Types, wie z.B. dynamische Arrays.
Zum Glück macht Delphi hier heimlich, und ohne was zu sagen, ein VAR daraus.

Bei OUT ist es möglich auch die Referenz zu ändern, was hier "eigentlich" zu einem Speicherleck führen würde, wenn vor dem Aufruf das Array einen Inhalt hätte.

Hast Du auch einen Vorschlag wie man das in einer Assembler-Routine realisieren kann (32BitAsm und 64BitAsm)?
Ich hatte das vor langer Zeit mal versucht.
Weiß nicht mehr woran es scheiterte, hab aber die unangenehme Erinnerung, dass ich es nicht hingekriegt habe, was aber nicht wirklich der Grund für meine Vorgehensweise war.
Ich hab die Funktion ja im Zusammenhang mit Mersenne-Primzahlen und den daraus abgeleiteten Perfekten Zahlen geschrieben.
Die zZ längste Zahl "(2^136279841-1) * 2^(136279841-1)" hat 82,048,640 Ziffern.
Rein theoretisch müsste ich, um auf der sicheren Seite zu liegen, das Array auf eine Länge von 82,048,640 setzen = 330MB.
Es ist aber so, dass mein Programm, dann wenn eine Zahl geladen wird, zählt, welche Ziffer wie oft vorkommt.
Am häufigsten, bei der og Zahl die 7 (8,202,366 Mal).
Also muss ich das Array "nur" auf eine Länge von 8,202,366 setzen = 33MB.
In einer allgemeingültigen Funktion ist eine Abschätzung, wie lang das Array sein muss eher nicht möglich.
Wenn ich wiederholte Längenänderungen vermeiden will müsste ich also für eine Suche nach einzelnen Zeichen die Länge auf die Länge des zu durchsuchenden Strings setzen, ZZ 330MB, bei den nächsten Mersenne-Primzahlen sicherlich > 1GB, und dann wird es problematisch.
Unabhängig davon wüsste ich aber gern, wie man ein SetLength in Assembler realisieren kann.

[Blup]

Zitat von himitsu:

Per se ist OUT hier falsch, jedenfalls in Bezug auf Managed-Types, wie z.B. dynamische Arrays.
Zum Glück macht Delphi hier heimlich, und ohne was zu sagen, ein VAR daraus.

Bei OUT ist es möglich auch die Referenz zu ändern, was hier "eigentlich" zu einem Speicherleck führen würde, wenn vor dem Aufruf das Array einen Inhalt hätte.

Da Managed-Types immer initialisisert sind, wäre OUT nach deiner Auffassung für diese immer falsch.
OUT intern für Managed-Types als VAR zu behandeln macht Delphi schon richtig, beide übergeben einen Zeiger auf die Variable.

Was meiner Meinung nach fehlt ist eine Warnung auch für Managed-Types.
- VAR-Parameter: Warnung wenn vorher keine Zuweisung auf die Variable erfolgt (kann auch leer sein, aber automatische Initialisierung zählt nicht)
- OUT-Parameter: Warnung wenn vorher eine Zuweisung auf die Variable erfolgt, diese Variable aber nicht mehr vor dem Aufruf als OUT-Parameter ausgewertet wird.

[Blup]

Zitat von Amateurprofi:

Und wo ist da der Fehler?
"PaPa" wird in "PaPaPa" an Position 1 gefunden.
Dann wird geprüft, ob ab hinter der Fundstelle, also ab Position 1+Length("PaPa") der Text "PaPa" noch einmal gefunden wird.
Das ist nicht der Fall, also wird korrekt 1 zurückgegeben.

Das ist Ansichtssache. Bei einer Funktion die Sucht und Ersetzt wäre dies auch sicherlich richtig.
Bei einer Funktion die alle Fundstellen zurückgibt, erwarte ich alle, auch wenn die gefundenen Zeichenketten sich überschneiden.
Welche davon ignoriert werden, kann man beim Verarbeiten des Ergebnis der Suche entscheiden.

[Amateurprofi]

Zitat von Blup:

Zitat von Amateurprofi:

Und wo ist da der Fehler?
"PaPa" wird in "PaPaPa" an Position 1 gefunden.
Dann wird geprüft, ob ab hinter der Fundstelle, also ab Position 1+Length("PaPa") der Text "PaPa" noch einmal gefunden wird.
Das ist nicht der Fall, also wird korrekt 1 zurückgegeben.

Das ist Ansichtssache. Bei einer Funktion die Sucht und Ersetzt wäre dies auch sicherlich richtig.
Bei einer Funktion die alle Fundstellen zurückgibt, erwarte ich alle, auch wenn die gefundenen Zeichenketten sich überschneiden.
Welche davon ignoriert werden, kann man beim Verarbeiten des Ergebnis der Suche entscheiden.

Zu "Bei einer Funktion die Sucht und Ersetzt wäre dies auch sicherlich richtig."
Ja, und meine Ansicht ist, dass eine Suche genau die Fundstellen finden soll, die im Zweifelsfall auch ersetzt würden.

Aber, wie du sagtest: Ist Ansichtssache.
Ich bin zum Beispiel der Ansicht, dass 2 * 2 = 5 ergeben sollte, wenn in 2024 der 31te eines Monats auf einen Montag fällt.