Verständnis von Abbruchbedingung

[SeppJ]

*p ist quasi *p != '\0' . Daher ist *p != '\0' && *p != ':' nicht identisch mit *p != ':' . Nur für einen speziellen Sonderfall ist es, wie von Bashar beschrieben, identisch. Aber die zusätzliche Sicherheit bei dieser Prüfung würde ich nicht weglassen, selbst wenn der Sonderfall gegeben ist. Wenn irgendjemand Müll in deine IP-Adresse schmuggeln kann, dann wäre ein Weglassen der Zusatzprüfung auf 0 fatal.

[volkard]

SeppJ schrieb:

*p ist quasi *p != '\0' . Daher ist *p != '\0' && *p != ':' nicht identisch mit *p != ':' . Nur für einen speziellen Sonderfall ist es, wie von Bashar beschrieben, identisch. Aber die zusätzliche Sicherheit bei dieser Prüfung würde ich nicht weglassen, selbst wenn der Sonderfall gegeben ist. Wenn irgendjemand Müll in deine IP-Adresse schmuggeln kann, dann wäre ein Weglassen der Zusatzprüfung auf 0 fatal.

Ich würde nicht prüfen.
Und falls doch, dann nicht in der Laufbedingung, sondern vorher, wo Programmierfehlerbehandlungscode hingehört.

[berniebutt]

In einer for-Schleife benutze ich nur klare übersichtliche Dinge für die Laufvariable und die Abbruchbedingung, am besten vom Typ int. In dem gefragten Fall ist zu einer while-Schleife mit einer in der Schleife zu verändernden Abbruchbedingung (von TRUE auf FALSE) zu raten. Für Testzwecke und zur Vermeidung einer Endlosschleife empfiehlt sich weiter ein Schleifenzähler zum gewaltsamen Abbruch mit break.

[SeppJ]

berniebutt schrieb:

In einer for-Schleife benutze ich nur klare übersichtliche Dinge für die Laufvariable und die Abbruchbedingung, am besten vom Typ int. In dem gefragten Fall ist zu einer while-Schleife mit einer in der Schleife zu verändernden Abbruchbedingung (von TRUE auf FALSE) zu raten. Für Testzwecke und zur Vermeidung einer Endlosschleife empfiehlt sich weiter ein Schleifenzähler zum gewaltsamen Abbruch mit break.

Boah. Ich hasse dieses Programmiermuster. Was soll denn da der Vorteil sein? Das ist genau, warum so viele Leute Vorurteile gegen strukturierte Programmierung hatten/haben.

[berniebutt]

SeppJ schrieb:

Boah. Ich hasse dieses Programmiermuster. Was soll denn da der Vorteil sein? Das ist genau, warum so viele Leute Vorurteile gegen strukturierte Programmierung hatten/haben.

Boah. Der Begriff 'Strukturierte Programmierung' stammt aus den 70er Jahren und hiess nichts anderes als klare Bedingungen in jedem Programmblock (z.B. einer Schleife) für input und output zu sorgen. Jeder Programmblock muss für jeden möglichen input einen ordentlichen output liefern oder mitteilen, warum das nicht möglich ist. Nichts anderes vertrete ich hier. Eine for-Schleife ist für anfangs bekannte Bedingungen geeignet, anderenfalls nimmt man besser z.B. eine while-Schleife.

[SeppJ]

Aber for (p = ipaddr_port; *p && *p != ':'; p++, i++); ist auch total strukturiert. Wenn du jetzt aus Angst vor einem kleinen UND und einer nicht-0815-Zählanweisung gleich mit einem bool boolean = true; while(boolean)...if(bedingung) boolean = false; ... ankommst, dann bestätigt das alle Vorurteile, dass strukturierte Programmierung grundsätzlich plump und unhandlich ist.

[Bashar]

SeppJ schrieb:

Vorurteile, dass strukturierte Programmierung grundsätzlich plump und unhandlich ist.

Das ist mir neu, dass das Vorurteile seien.

[SeppJ]

Bashar schrieb:

SeppJ schrieb:

Vorurteile, dass strukturierte Programmierung grundsätzlich plump und unhandlich ist.

Das ist mir neu, dass das Vorurteile seien.

Wenn man es so macht wie beschreiben, dann ist das selbstverständlich kein Vorurteil. Muss man aber nicht. Man kann ja auch for (p = ipaddr_port; *p && *p != ':'; p++, i++); schreiben, das finde ich auch sehr strukturiert. Wenn man noch einen Kommentar dranschreibt, dass die Schleife p bis zum Ende oder bis zum nächsten Doppelpunkt hochzählt und i die Zeichen mitzählt, dann hätte bestimmt auch Niklaus Wirth nichts dagegen.

[volkard]

berniebutt schrieb:

Boah. Der Begriff 'Strukturierte Programmierung' stammt aus den 70er Jahren und hiess nichts anderes als klare Bedingungen in jedem Programmblock (z.B. einer Schleife) für input und output zu sorgen. Jeder Programmblock muss für jeden möglichen input einen ordentlichen output liefern oder mitteilen, warum das nicht möglich ist.

Naja, ein wenig mehr Forderungen schon. Zum Beispiel Single-Exit.

berniebutt schrieb:

Eine for-Schleife ist für anfangs bekannte Bedingungen geeignet, anderenfalls nimmt man besser z.B. eine while-Schleife.

Da bin ich meistens ganz Deiner Meinung.

//Verletzung der single-exit-Forderung
//Nicht strukturiert. 
for (p = ipaddr_port; *p ; p++, i++)
  if (*p == ':')
    return i;
return -1;

versus

for (p = ipaddr_port; *p && *p != ':'; p++, i++);
return *p ? i : -1;

[Namenloser324]

Ok, vielen Dank.