Kann man diese Funktion noch weiter optimieren?

**luke2**

Danke nochmal! Ich denke so kann ich das nehmen.

**samso**

Öhh, kann das sein, dass dieser Algorithmus nun Zeilen, die nur mit #10 enden nicht mehr findet?

**alzaimar**

Ja. Danach war doch nicht gefragt, oder? Die Optimierung besteht im Wegnehmen einer Abfrage (auf #10) prüfen.

**samso**

Zitat von luke2:

die durch #13, #10 oder #13#10 getrennt sind

Also ich lese das als: #13 oder #10 oder #13#10. Finde ich auch irgendwie sinnvoll, weil so eine typische Linux-Zeile mit #10 endet.

**Phoenix**

Zitat von alzaimar:

Ja. Danach war doch nicht gefragt, oder?

Also wenn ich mir das OP so angucke eigentlich nicht:

Zitat von luke2:

also eigentlich nur Strings, die durch #13, #10 oder #13#10 getrennt sind, zu extrahieren.

Was ist nun mit den #10 ern?

luke2 Registriert seit: 17. Jun 2009 117 Beiträge	#11 Re: Kann man diese Funktion noch weiter optimieren? 15. Jul 2009, 20:52 Danke nochmal! Ich denke so kann ich das nehmen.
	Zitat

samso Registriert seit: 29. Mär 2009 439 Beiträge	#12 Re: Kann man diese Funktion noch weiter optimieren? 16. Jul 2009, 15:56 Öhh, kann das sein, dass dieser Algorithmus nun Zeilen, die nur mit #10 enden nicht mehr findet?
	Zitat

alzaimar (Moderator) Registriert seit: 6. Mai 2005 Ort: Berlin 4.956 Beiträge Delphi 2007 Enterprise	#13 Re: Kann man diese Funktion noch weiter optimieren? 16. Jul 2009, 16:31 Ja. Danach war doch nicht gefragt, oder? Die Optimierung besteht im Wegnehmen einer Abfrage (auf #10) prüfen. "Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!" (Monty Python "Joke Warefare")
	Zitat

samso Registriert seit: 29. Mär 2009 439 Beiträge	#14 Re: Kann man diese Funktion noch weiter optimieren? 16. Jul 2009, 16:39 Zitat von luke2: die durch #13, #10 oder #13#10 getrennt sind Also ich lese das als: #13 oder #10 oder #13#10. Finde ich auch irgendwie sinnvoll, weil so eine typische Linux-Zeile mit #10 endet.
	Zitat