String Code überprüfen

[Furtbichler]

Wie man ernsthaft (hier) *gegen* den Einsatz von RegEx sein kann, ist mir ein Rätsel. Man kann das natürlich per Hand auskodieren, aber RegEx ist einfach zu einfach :stupid:

Die Fragestellung zielt ganz klar in Richtung Mustererkennung. "Anfang der Zeile", "O<Ziffern><PlusOderMinus>". Ergo ist ein Zeichen-Mustererkenn-O-Mat, aka 'regular expression', das richtige Werkzeug.

Die erkannten regulären Ausrücke (O<Zahl><PlusMinus>) müssen dann nur noch hinsichtlich der 'Zahl' geprüft werden (um 1 inkrementierend).

Der reguläre Ausdruck kann natürlich im Einzelfall ziemlich komplex und sehr(!) schlecht zu lesen sein, aber es gibt mittlerweile RegEx-formatierer und -Kommentierer, die selbst den perversesten Ausdruck verständlich darstellen können.

Hier sind dann übrigens im Einzelfall Kommentare angebracht, obwohl ich sonst kein Freund davon bin.

@Amateurprofi: Googel mal nach "Delphi regEx", druck dir die Ergebnisse aus, stell dich in 100m Entfernung vor den Ausdruck, nimm einen Dartpfeil und werfe rückwärts mit geschlossenen Augen. Du triffst *garantiert* etwas Brauchbares ;-)

Oder Du bist Pazifist und suchst in der DP

Es geht ja nicht konkret um die exakte Unit, sondern das Verfahren.

Zitat:

Zitat von Amateurprofi (Beitrag 1175512)

Zum Beispiel kann nicht geprüft werden, ob da vielleicht ein Oxx nicht am Zeilenanfang steht...Ein weiteres Problem, nämlich Oxx zu finden, bei denen das xx nicht direkt dem "O" folgt wird ebenfalls nicht gelöst.

Wir lesen die Aufgabenstellung:

Zitat:

Zitat von lemomo (Beitrag 1174866)

Es muss auch überprüft werden ob unser String auf die erste Reihe geschrieben ist und ob sein Integer Teil sich richtig inkrementiert.

[idefix2]

Zitat:

Der reguläre Ausdruck kann natürlich im Einzelfall ziemlich komplex und sehr(!) schlecht zu lesen sein,

Das ist richtig. Fairerweise muss man aber dazu sagen, dass dann der Fall sein wird, wenn das zu erkennende Muster ziemlich komplex ist, und dass ein Programm, das die Erkennung eines so komplexen Musters ausprogrammiert, noch um ein Vielfaches schwieriger zu lesen sein wird als der regex-String.

[Furtbichler]

Manchmal ist ein DEA einfacher zu verstehen. Heißt aber nicht, das ein Regex abzulehnen wäre.

[Amateurprofi]

Zitat:

Zitat von Furtbichler (Beitrag 1175535)

Wie man ernsthaft (hier) *gegen* den Einsatz von RegEx sein kann, ist mir ein Rätsel. Man kann das natürlich per Hand auskodieren, aber RegEx ist einfach zu einfach :stupid:

Die Fragestellung zielt ganz klar in Richtung Mustererkennung. "Anfang der Zeile", "O<Ziffern><PlusOderMinus>". Ergo ist ein Zeichen-Mustererkenn-O-Mat, aka 'regular expression', das richtige Werkzeug.

Die erkannten regulären Ausrücke (O<Zahl><PlusMinus>) müssen dann nur noch hinsichtlich der 'Zahl' geprüft werden (um 1 inkrementierend).

Der reguläre Ausdruck kann natürlich im Einzelfall ziemlich komplex und sehr(!) schlecht zu lesen sein, aber es gibt mittlerweile RegEx-formatierer und -Kommentierer, die selbst den perversesten Ausdruck verständlich darstellen können.

Hier sind dann übrigens im Einzelfall Kommentare angebracht, obwohl ich sonst kein Freund davon bin.

@Amateurprofi: Googel mal nach "Delphi regEx", druck dir die Ergebnisse aus, stell dich in 100m Entfernung vor den Ausdruck, nimm einen Dartpfeil und werfe rückwärts mit geschlossenen Augen. Du triffst *garantiert* etwas Brauchbares ;-)

Oder Du bist Pazifist und suchst in der DP

Es geht ja nicht konkret um die exakte Unit, sondern das Verfahren.

Zitat:

Zitat von Amateurprofi (Beitrag 1175512)

Zum Beispiel kann nicht geprüft werden, ob da vielleicht ein Oxx nicht am Zeilenanfang steht...Ein weiteres Problem, nämlich Oxx zu finden, bei denen das xx nicht direkt dem "O" folgt wird ebenfalls nicht gelöst.

Wir lesen die Aufgabenstellung:

Zitat:

Zitat von lemomo (Beitrag 1174866)

Es muss auch überprüft werden ob unser String auf die erste Reihe geschrieben ist und ob sein Integer Teil sich richtig inkrementiert.

Genau, wir lesen die Aufgabestellung

Zitat:

Zitat von lemomo (Beitrag 1174866)

Es muss auch überprüft werden ob unser String auf die erste Reihe geschrieben ist und ob sein Integer Teil sich richtig inkrementiert.

[/QUOTE]

Und genau das wird eben nicht gelöst.
Wenn zum Beispiel in der Datei die Zeilen
"O27"
"..."
" O28"
"..."
"O28"
stehen, dann würde das eingerückte "O28" übergangen, der Fehler also nicht bemerkt.
Lemomo will ja nicht nur die "Oxx" finden die korrekt sind, sonder er möchte eine komplette Prüfung seiner Datei.
In der Tat!

[Furtbichler]

Dann wird die Regex eben erweitert.
Um genau 2 Zeichen. Oder ein paar mehr.
WTF

Die semantische Prüfung der aufsteigenden Werte erfolgt über einen Dreizeiler.

[idefix2]

Zitat:

Zitat von Amateurprofi (Beitrag 1175570)

Wenn zum Beispiel in der Datei die Zeilen
"O27"
"..."
" O28"
"..."
"O28"

Ja, das stimmt. Aber jedes O, das irgendwo im Text vorkommt, und das nicht von einer passenden Zahl gefolgt wird, als Fehler auszuweisen, kann es sicher auch nicht sein. Die Aufgabenstellung ist sehr schwammig formuliert, und der TE hat sich ja schon lange nicht mehr gemeldet. Wir können also nur darüber spekulieren, wie in so einem Sonderfall vorzugehen ist, und das ist wohl nicht sonderlich sinnvoll.

Mir ist es nur darum gegangen, aufzuzeigen, wie einfach die Lösung derartiger Probleme mit Hilfe von regex ist, verglichen mit dem sturen Ausprogrammieren der Mustererkennung.

Zitat:

Manchmal ist ein DEA einfacher zu verstehen

Ich verstehe Bahnhof.

[Furtbichler]

Zitat:

Zitat von idefix2 (Beitrag 117557)

Ich verstehe Bahnhof.

Man kann das Erkennen von regulären Ausdrücken auch über einen Zustandsautomaten abbilden. Das ist dann eine Schleife über den Eingabetext mit einer Case-Anweisung.

Um auch O's im Text zu erkennen, kann man ein zweites Muster angeben, das diesen Fall abdeckt.

[omata]

Zitat:

Zitat von Amateurprofi (Beitrag 1175512)

Frage : Welche denn ?

Zitat:

Zitat von dunningkruger (Beitrag 1175517)

Interessiere mich so langsam auch für einen RegEx-Link (unit oder Komponente mit Doku) für Delphi 5.

siehe auch hier.

[Amateurprofi]

QUOTE=idefix2;1175578]

Zitat:

Zitat von Amateurprofi (Beitrag 1175570)

Wenn zum Beispiel in der Datei die Zeilen
"O27"
"..."
" O28"
"..."
"O28"

Ja, das stimmt. Aber jedes O, das irgendwo im Text vorkommt, und das nicht von einer passenden Zahl gefolgt wird, als Fehler auszuweisen, kann es sicher auch nicht sein. Die Aufgabenstellung ist sehr schwammig formuliert, und der TE hat sich ja schon lange nicht mehr gemeldet. Wir können also nur darüber spekulieren, wie in so einem Sonderfall vorzugehen ist, und das ist wohl nicht sonderlich sinnvoll.

Mir ist es nur darum gegangen, aufzuzeigen, wie einfach die Lösung derartiger Probleme mit Hilfe von regex ist, verglichen mit dem sturen Ausprogrammieren der Mustererkennung.

Zitat:

Manchmal ist ein DEA einfacher zu verstehen

Ich verstehe Bahnhof.[/QUOTE]

Genau das macht die von mir vorgeschlagene Prozedur eben nicht!
Nur "O"s, die das erste Non-Blank in einer Zeile sind, werden überprüft. "O"s, die irgendwo im Text stehen, selbstverständlich nicht.
Was in meiner Prozedur noch fehlt, ist die Angabe der Zeilennummer, in der ein Fehler vorkommt.
Weiterhin fehlt dir Prüfung ob einem "O" ein oder mehrere Blanks und diesen eine Zahl folgt. Anstatt wird ein "O" am Zeilenanfang, dem keine Ziffer folgt, als Fehler erkannt.

Was die "schwammige" Aufgabenstellung betrifft, sind wir exakt einer Meinung.

[Furtbichler]

Ich bin auch ein Freund von basisfunktionaler Programmierung, d.h. ohne 'Schnickschnack' wie RegEx usw.

Das heißt aber nicht, das ich mich nicht damit beschäftigte und dann, wenn es sinnvoll(er) ist, diese auch einzusetzen.

Hier könnte man eine kleine Sprache definieren, die aus den Symbolen (nennen wir sie 'On+'), Zeilenanfängen und sonstigem Text besteht.

Das macht man mit einem Lexer/Tokenizer, dessen Grundlage i.a. ein RegEx ist.

Man *kann* das auch handcodiert machen, aber -ehrlich gesagt- ich nehme gerne die Dienste von DHL, UPS o.ä. in Anspruch, auch wenn ich das Paket selbst abliefern könnte, vermutlich sogar etwas schneller, aber: WTF.

Mit Standardanbietern/-tools ist es einfach bequemer und ich weiss eins sicher: Es funzt.


Ach: Eins noch: Deine speziell implementierte Variante hat ein Problem: Sie ist nicht allgemeingültig. Du musst jedesmal das Rad neu erfinden. Macht Spass, aber ist auch irgendwie langweilig.