RegExp: Verschachtelte Block-Kommentare entfernen - Char nicht-in-String ersetzen

  • Mars , @alle

    Die Sammlung der RegExp's, die sich aus diesem und dem anderen Thread ergeben haben, habe ich in der "Reguläre Ausdrücke Sammlung" gepostet in Posting #36, als Funktion ReadFunctionHeads(), inklusive Demo.

    Dort habe ich mich bei allen bedankt, die sich an den Postings beteiligt und/oder am Code mitgearbeitet haben. Hier soll aber auch erwähnt sein, dass ich mich freue über die Hilfe von Bitnugger und Musashi beim Finden eines Namens für meine Funktion. Das ist mehr Arbeit, als man denkt. :P

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Antwort auf deine Fragen im Thread "Reguläre Ausdrücke Sammlung" Posting #38.

    Müssten die #region-#endregion nicht auch sowieso durch das Pattern "Alle Zeilen die nicht mit Func oder EndFunc angfangen" entfernt werden?

    Also wenn ja - warum dann eine Extra-Behandlung hierfür?

    Das dachte ich zuerst auch. Das Entfernen von #Region-#EndRegion habe ich für den Fall drin, wenn jemand auf die Idee kommt, seine Beschreibung mit einem Unterstrich zu beenden. :rolleyes: Der würde dann für eine Zeilenfortsetzungszeichen gehalten und im weiteren Code für Chaos sorgen. Beispiel:

    #Region Am Ende kann ein Unterstrich stehen _

    Zum Thema mehrfachen Leerraum entfernen: Es muss nicht immer RegEx sein..: StringStripWS(..., 4)

    Das hatte ich glaube ich mal getestet, und RegExp war schneller. Allerdings kann ich nicht mehr so genau sagen, ob auch StringStripWS bei den Test war (StringRepace war auf jeden Fall dabei).

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Hi Professor Bernd

    Ich weiß nicht, wie du das StringReplace umgesetzt hast (muss aber langsamer sein als StringStripWS). Aber die String Funktionen selbst sind eigentlich alle sehr schnell. Da würde ich nicht viel überlegen.

    Grüße autoiter

  • Mit StringStripWS habt ihr wohl recht, das kann man genauso gut benutzen. Ich habe gerade ein paar Tests durchgeführt, und RegExp und StringStripWS waren gleich schnell. (Die Tests waren mit der gleichen, simplen Zeitmessung per TimerInit wie im Demo. Die sind jetzt nicht sooo aussagekräftig, aber auf die Schnelle ist's in Ordnung.) :saint:

    Danke euch beiden für den Tipp! :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • AspirinJunkie autoiter

    Bitte vielmals um Entschuldigung, hier stand ein Code mit einem peinlichen Fehler drin. :Face: Aber nach Behebung des Fehlers gibt es nun einen anderen, der die Ausführung des Codes verhindert. Da bringe ich erstmal Ordnung rein und melde mich dann.

    ... tick tack, tick tack ...

    Das Rätsel ist gelöst! :) Auflösung siehe Posting #28.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    6 Mal editiert, zuletzt von Professor Bernd (6. Juli 2020 um 19:49)

  • Oh, wow, peinlicher Fehler bei StringStripWS im Posting #25! Werde ich dort korrigieren. Es gibt dann jedoch einen anderen Fehler => deshalb werde ich erst mal testen und melde mich dann.

    autoiter Gemeint ist dieses Demo.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • AspirinJunkie autoiter

    So, das Rätsel ist gelöst. StringStripWS ist NICHT als Ersatz für die RegExp zu gebrauchen, weil StringStripWS viel zu viel weghaut!

    Zitat

    Funktion StringStripWS

    $STR_STRIPSPACES (4) = entferne doppelte (oder mehr) Leerstellen zwischen den Zeichen

    Leerstellen schließen die ASCII Zeichen Chr(9) bis Chr(13) mit ein, die für Horizontal-Tabulator, Zeilenvorschub, Vertikal-Tabulator, Seitenvorschub und Wagenrücklauf stehen. Als Leerstellen gelten ebenfalls das Null-Zeichen ( Chr(0) ) sowie das Standard Leerzeichen ( Chr(32) ), das durch Drücken der Leertaste entsteht.

    Bernd.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Ja, so Fehler passieren schonmal im Eifer des Gefechts.

    Aber danke für den Hinweis. Ich meine, es steht natürlich klar in der Hilfe. Aber ich habe das gar nicht auf dem Schirm gehabt (-scheinbar noch nie auf einen ganzen Text angewendet). Aber das etwa aus crlf cr wird sollte man auf dem Schirm haben.

    Grüße autoiter

  • Ich meine, es steht natürlich klar in der Hilfe. Aber ich habe das gar nicht auf dem Schirm gehabt (-scheinbar noch nie auf einen ganzen Text angewendet).

    Ging mir genauso. Wenn ich so zurückblicke denke ich, ich habe das bisher tatsächlich nur auch kurze Strings angewendet, die keinen Zeilenumbruch enthielten. :/

    Auf jeden Fall habe ich wieder was gelernt und danke euch beiden für die Hinweise.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Müssten die #region-#endregion nicht auch sowieso durch das Pattern "Alle Zeilen die nicht mit Func oder EndFunc angfangen" entfernt werden? Also wenn ja - warum dann eine Extra-Behandlung hierfür?

    Das Entfernen von #Region-#EndRegion habe ich für den Fall drin, wenn jemand auf die Idee kommt, seine Beschreibung mit einem Unterstrich zu beenden. :rolleyes: Der würde dann für eine Zeilenfortsetzungszeichen gehalten und im weiteren Code für Chaos sorgen. Beispiel:

    #Region Am Ende kann ein Unterstrich stehen _

    In der SciTE Hilfe zu #Region/#EndRegion war nur folgendes zu finden:

    Zitat von Lexer features

    There is an additional folding keyword #region...#endregion to permit really large blocks of code to be compressed. Any text following these special keywords is considered a comment:

    Meine Annahme war, alles was hinter #Region steht, wäre wie ein Kommentar zu sehen. Nun habe ich festgestellt, dass dem nicht so ist. Es scheint dass zwar hinter #Region alles bis zum Zeilenende vom Compiler ignoriert wird, außer ein Leerzeichen+Unterstrich am Ende. Das heißt, der Compiler sieht das " _" sehrwohl als Zeilenfortsetzungszeichen (und nicht als Kommentar!).

    AspirinJunkie Wenn meine Annahme richtig ist, und das Zeilenfortsetzungzeichen vom Compiler auch hinter #Region erkannt wird, dann kann ich das Entfernen von #Region/#EndRegion Zeilen sparen.

    Kann das jemand bestätigen und/oder was dazu sagen?

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Neue Erkenntnis: Der Fehler tritt nur auf, wenn #Region in der ersten Zeile eines Scripts steht. Ich habe die Frage nun auch im EN Forum gepostet.

    Test-Beispiel
    AutoIt
    #Region Bug only occurs when #Region is in the first line _
    Func Example()
      MsgBox(0, "", "hello")
    EndFunc
    #EndRegion
    
    Example()

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.