Zeilen in einem String zählen

[himitsu]

Das zweite Inc(P) gehört zur #13 und das erste zur #10. (darum nochmal die Drehung im zweiten Code)

Delphi-Quellcode:

while P^ <> #0 do
  if P^ = #13 then begin
    Inc(Result);
    if (P + 1)^ = #10 then // nächstes Zeichen
      Inc(P); // #10
    Inc(P); // #13
  end else if P^ = #10 then begin
    Inc(Result);
    Inc(P); // #10
  end else
    Inc(P); // Rest


while P^ <> #0 do
  if P^ = #13 then begin
    Inc(Result);
    Inc(P); // #13
    if P^ = #10 then
      Inc(P); // #10
  end else if P^ = #10 then begin
    Inc(Result);
    Inc(P); // #10
  end else
    Inc(P); // Rest

Letzteres ist also die direkte/ursprüngliche Funktionsweise und beim ursprünglichen Code wurde das alles in einen etwas kürzeren Code optimiert.
Dieses Erste entspricht von der Funktion dem Urspungscode, nur daß ursprünglich eben die dreifachen Inc(P) zu Einem zusammengefast und aus den IFs rausgeholt waren.



Früher war #13#10 der Zeilenumbruch (kennt man vorallem von den Druckern ... CR/CarriageReturn/#13 zurück zum Zeilenanfang + LF/LineFeed/#10 zur nächsten Zeile)
Windows macht das standardmäßig immernoch so.

Linux wollte sparen, drum nutzen die standardmäßig nur noch #10, wo implizit das Carriage Return mit enthalten ist.

Macintosh kochte sein eigenes Süppchen und dachte sich #13 wäre auch ein guter Zeilenwechsel, obwohl das syntaktisch nun überhaupt nicht stimmt.

Windows selber unterstützt standardmäßig alles (vorallem #13#10 und #10), aber z.B. im neuen RichEdit-Control v3 hat man totalen Mist gebaut und dort wird das #13 als Zeilenumbruch verwendet (keine Ahnung warum).

#10#13 währe teschnich gesehn auch ein Zeilenumbruch, aber dieses wird als #10 und #13 angesehn, also zwei Zeilenumbrüche.
Vermutlich weil es einfacher zu implementieren war, bzw. bei der implementierung keiner dran gedacht hat (währe aber auch nur ein IF+INC mehr).