String einen substring über mehrere Zeilen

Sone

SeppJ schrieb:

Wow, mein Rechner setzt erst einmal eine Sekunde aus, wenn er den Tab mit dem Quelltext lädt .

Langsamer Rechner, nicht wahr?

Hier die Geschwindigkeiten, die ich gemessen habe:

Kritticker: 3547000 
Sone:       1210000
SeppJ:      710000

Verdammt, da hat der SeppJ aber Schwein. Nur weil ich so viel drumherum habe.

SeppJ

Das ist kein Glück. Was erwartet ihr denn von solch fetten Codes? Gerade die Regex von Kritticker sind Overkill³. Bei dir kann man wenigstens sagen, dass dein Code mehr kann.

Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft.

knivil

Nun, wenn eine Bibliothek mir Exceptions entgegenwirft, nur weil sie mit ein paar falschen Eintraegen konfrontiert wird, dann wuerde ich die Bibliothek wechseln.

Supi! Sollte es auch sein. Ein möchtegern-Perfektionist wie ich...

Code sollte einfach sein.

Ich hätte einfach ne XML & nen einfachen XML Parser wie irrXML genommen...

knivil

Es ist grundsaetzlich falsch, die Worte 'einfach' und XML in einem Satz zu sagen.

knivil schrieb:

Es ist grundsaetzlich falsch, die Worte 'einfach' und XML in einem Satz zu sagen.

Wieso? Man brauch nicht für jeden Furz nen Xercxes Parser und andere Späße mit tausendfacher DOM Validierung und ähnlichem Kram.
Manchmal ist weniger einfach mehr.
irrXML ist schnell, einfach. Kann dafür wenig.
Aber solange man nur lesen will und nicht validieren, sehe ich daran nichts falsches.

knivil

Habe ich von irrXML als Bibliothek gesprochen? Nein!

PS: Habe gerade irrXML-Api ueberflogen. Sorry, im Vergleich zu anderen XML-Gedoens ist es vielleicht leichtgewichtig, aber im Vergleich zu ini-Parser oder JSON-Parser trotzdem Schwergewicht. Es ist auch schwer zu sagen, wie fehlertolerant irrXML ist. Bei ini-Files sehr einfach zu bewerkstelligen, naja, ausser Sones Implementierung, die mit Exceptions um sich wirft.

Man kann natürlich auch JSON nehmen. Mir wayne. Mir gings nur darum, dass man lieber auf bewährte Dinge setzen sollte als sich das Leben unnötig schwer zu machen.

hustbaer

was anderes schrieb:

Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft.

Exceptions zu übersetzen ist natürlich die ganz tolle Idee.

Darf ich fragen was du mit deinem Beitrag sagen willst?

hustbaer schrieb:

was anderes schrieb:

Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft.

Exceptions zu übersetzen ist natürlich die ganz tolle Idee.

Darf ich fragen was du mit deinem Beitrag sagen willst?

Ich wollte damit einfach nur sagen das der Exception-Text im UI-Layer zusammengebaut werden sollte. Die Exception-Klasse sollte alle Informationen dazu beinhalten, aber nicht den Text selbst.

hustbaer

@was anderes
Und ich bin der Meinung dass das für viele Applikationen Overkill ist.

Und selbst dort wo es kein Overkill ist, will ich in der Exception selbst eine (verständliche, englische) Error-Message haben die bei what() zurückkommt. Und sei's nur zum Debuggen und/oder Loggen.

Was ich bei der Sache allerdings schade finde, ist, dass die Standard-Library hier nicht mehr vorgibt. Also z.B. ne Möglichkeit einen Error-Code (z.B. in String-Form). Oder gleich die Möglichkeit in der Exception ein Objekt abzulegen das von irgend einer Basisklasse ("error_info") abgeleitet ist. Dort wäre dann auch schön Platz um diverse Zusatzinformationen ala Filename, System Error-Code, Username etc. abzulegen.

Exception-Chaining wäre auch sehr hilfreich.

Nagut, darum geht's ja hier nicht. Also [/OT]

knivil

Warum sollte man einer Exception mehr Information mitgeben als einen String fuer eine anstaendige Fehlermeldung. Nun man koennte den Fehlerfall ausgleichen und das Parsen an einem sicheren Punkt fortfuehren. Da finde ich aber Fehlerbearbeitungsfunktionen besser, die beim Start des Parsens der Funktion einfach mitgegeben werden. Exceptions halte ich fuer ungeeignet.

hustbaer

@knivil
Der Wunsch einer Exception Zusatzinfos mitgeben zu wollen ist nicht auf den Anwendungsfall "Ini-Parser" bezogen, sondern allgemein.

Je mehr Informationen ich aus der Exception rausbekomme, desto eher kann ich mit wenigen bis sehr wenigen catch-Stellen auskommen, ohne wertvolle Informationen im Logfile zu verlieren.

Da ich kein Fan von try-catch-rethrow bin, sondern ein einziges zentrales "catch" als anzustrebenden Idealfall ansehe... => doof dass std::exception so wenig kann.