Mit break aus for(..;..;..) raus?

darthdespotism

hustbaer schrieb:

darthdespotism schrieb:

Das Problem entfällt natürlich mit std::tr1::smart_pointer & co.

Das Problem gab es nie seit Gott damals std::auto_ptr erfunden hat, und uns Menschen erlaubt selbst ähnliche Klassen (RAII) zu schreiben.

Eben das habe ich mit meinem letzten Satz aussagen wollen. Es gibt aber immer noch jede Menge Leute die so mit Pointern umgehen (vielleicht gibts performance-Gründe, vll nicht)

Shogun

Also ich hab mir zur Gewohnheit gemacht in SChleifen break zu benutzen, wenn ich wirklich schnell raus will ohne noch viele Operationen durhczuführen... Nur sollte man wissen was man tut. Dann gibt es auch keine technischen Probleme.

Jester schrieb:

Was genau bedeutet für euch "mathematisch validierbar"?

validieren -> prüfen

Wie geht das bei einer Schleife, die mehrere Laufbedingungen hat ?
Wie geht das bei einer Funktion, die so eine Schleife enthält ?

"Logik" alleine ist nicht ausreichend.

hustbaer

Naja, mutable State is nicht gut für "Beweisbarkeit".
Eine einfache Schleife ala "for x = 0 to 100" lässt sich meist auch relativ einfach "mathematisch" darstellen.
Wenn man allerdings etwas hat ala...

bool foo = true;
for (int x = 0; (x <= 100) && foo; x++)
{
    // ...
    if (...)
        foo = false;
}

...dann hat man oft schon ein Problem. Die Korrektheit der Schleife oben lässt sich allerdings genauso schwer oder einfach beweisen wie die folgendermassen umgeformte:

for (int x = 0; x <= 100; x++)
{
    // ...
    if (...)
        break;
}

Einfacher zu beweisen wird es bloss wenn man ausschliesslich Abbruchbedingungen verwendet die es einem erlauben mit wenig Aufwand die Anzahl der Durchläufe zu bestimmen.

Simon2

rüdiger schrieb:

Einfache Regel: Alle Abbruchbedingungen, die man ohne Probleme im "Schleifenkopf" einbringen kann, bringt man dort ein. Alle anderen nicht.

Ein Zwang sorgt nur für unleserlichen Code! Viel wichtiger ist es kurze Funktionen (also auch schleifen) zu schreiben. Wenn eine Schleife mehr als (sagen wir mal) 5 Zeilen hat, verliert man ohnehin schnell die Übersicht und sollte lieber Unterfunktionen benutzen....

Genau so meinte ich das.

Jester schrieb:

Simon2 schrieb:
while(irgendeine Bedingung && !(erste Operation erfolgreich))
   zweite Operation
Wieso nicht ?
Mach bitte aus erste Operation was zwei- oder dreizeiliges.

Was meinst Du damit ? Mehrere Funktionsaufrufe ? Ein Funktionsaufruf mit 20 Parametern ? ...
In jedem Fall wirst Du es auf einen bool herunterbrechen und den kannst Du ebensogut in die Abbruchbedingung (und ggf. zusätzlich in ein if for "zweite Operation") packen.
Aber (wie ich auch schon gesagt habe) irgendwann KANN die Komplexität ein break sinnvoller machen. Trotzdem halte ich die Regel "break nur im absoluten Ausnahmefall" für sinnvoll, weil sie einen dazu zwingt, sich ein paar mehr Gedanken über Übersichtlichkeit und Komplexität zu machen.
Wer break als Defaultweg ansieht, findet sich schnell in der Wartungshölle wieder.
(Auch Schleifen mit break sind nicht wirklich übersichtlich ... aber im Extremfall vielleicht übersichtlicher als ihre "breaklosen Pendants")

Gruß,

Simon2.

Simon2

darthdespotism schrieb:

...
Kann in längeren Schleifen zu schwehr auffindbaren Speicherlecks führen.
=> throw, break, continue können zu Speicherleks führen, wenn "rohe" Pointer im Spiel sind. Ein throw zu verhindern ist, wenn Biblioteken im Spiel sind eher schwehr....

Deswegen ist es aber IMO kein Argument gegen break.

Gruß,

Simon2.

Jester

merker schrieb:

Jester schrieb:

Was genau bedeutet für euch "mathematisch validierbar"?

validieren -> prüfen

Danke, das wußte ich nicht.
Im Ernst: haste vielleicht ne vernünftige Definition dafür?

Ansonsten sehe ich da nicht wirklich Probleme. Man kann doch trotzdem ne Vor/Nachbedingung und ne Invariante definieren. Klar, man kriegt ne zusätzliche Fallunterscheidung im Beweis rein, aber ich sehe nicht warum das ein grundsätzliches Problem sein sollte (übrigens bei while-Schleifen genausowenig).

BorisDieKlinge

"break" is geil

Kolumbus

Hallo,

ein Online-Fremdwörterbuch ( http://services.langenscheidt.de/fremdwb/fremdwb.html ) sagt dazu:

va·li'die·ren 1. RECHT etwas für rechtsgültig erklären 2. die Gültigkeit eines wissenschaftlichen Ergebnisses überprüfen

MfG

Edit: übrigens:

ma·the'ma·tisch die → Mathematik betreffend, auf ihr beruhend, zu ihr gehörend, mit ihrer Hilfe

Ma·the·ma'tik, die; -, keine Mehrzahl 1.Wissenschaft von den Zahlen- und Raumgrößen 2.(1) als Lehrfach

Jester

Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

edit: Wenn ihr der Meinung seid, die Definition sei damit ausreichend klar, dann könntet ihr ja mal zu meiner zweiten Frage kommen.

Kuldren

hm...dachte mir eh schon dass es hier ziemlich gespaltene meinungen gibt...
ich werd nach wie vor boolflags so gestalten dass möglichst alle abbruchbedingungen im schleifenkopf stehen...
und ggf. werd ich wohl auch mal break verwenden wenn ich damit die (meist) großen if-ummantelungen umgehen kann!!
danke jedenfalls mal für die vielen antworten!

Apollon

Ich versuchs mal. Jede Schleife hat eine Vorbedingung und eine Nachbedingung. Desweitere hat jede Schleife ein Invariante. Die Invariante muss entweder zu jedem Zeitpunkt gueltig sein oder zumindest zu bestimmten Zeitpunkten (totale und partielle Korrektheit). Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.

EDIT: Argh! Quetscht sich da einer dazwischen!

Kolumbus

Jester schrieb:

Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

Falls Du mich meintest: Habe ich irgendwo behauptet mit meinem Post Deine Definitionsfrage zu beantworten? ... Also nörgel nicht rum.

Aber wenn man nicht zum allgemeinen Begriffsverständnis beitragen soll, kann ich das in Zukunft auch lassen! *BockigInDerEckeSteh*

Jester

Apollon schrieb:

Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.

Ja, das könnte sein. Allerdings ist dann entweder das Programm oder die Nachbedingung (oder beides) falsch. Ist das Programm korrekt, so sehe ich kein Problem darin, die Nachbedingung so abzuändern, dass sie das Programm auch korrekt beschreibt. Programme, die nicht zu einer gegebenen Spezifikation passen lassen sich schließlich auch ohne break schreiben.

Jester

Kolumbus schrieb:

Jester schrieb:

Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

Falls Du mich meintest: Habe ich irgendwo behauptet mit meinem Post Deine Definitionsfrage zu beantworten? ... Also nörgel nicht rum.

Oh, entschuldige. Ich werde in Zukunft davon ausgehen, dass Du einfach so zusammenhangslos irgendwelche Sachen in Threads reinkopierst.

Aber wenn man nicht zum allgemeinen Begriffsverständnis beitragen soll, kann ich das in Zukunft auch lassen! *BockigInDerEckeSteh*

Was hilft das denn bitte für's Verständnis? Das hilft ungefähr so viel wie "Was ist ein Vektorraum?" -- "Ein Raum mit/von/aus Vektoren!".

Apollon

Jester schrieb:

Apollon schrieb:

Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.

Ja, das könnte sein. Allerdings ist dann entweder das Programm oder die Nachbedingung (oder beides) falsch. Ist das Programm korrekt, so sehe ich kein Problem darin, die Nachbedingung so abzuändern, dass sie das Programm auch korrekt beschreibt. Programme, die nicht zu einer gegebenen Spezifikation passen lassen sich schließlich auch ohne break schreiben.

Nicht, dass wir uns an dieser Stelle falsch verstehen. Ich bin kein Gegner von break und von dem Verifikationsproblem im Zusammenhang mit break hoere ich hier zum ersten Mal. Ich vertrete nur die Meinung, dass es immer ohne geht. Durch diesen Thread faellt mir nur auf, dass ich break sehr selten benutze ohne dabei den Code bewusst so zu gestalten, dass break unnoetig ist.

Ich bin jetzt auch nicht in der Lage, ein nichttriviales Beispiel zu geben, weil Invariantenbestimmung keine einfache Sache ist. Ueberhaupt gehe ich davon aus, dass irgendwannmal irgendjemand einen Fall gefunden hat, wo break tatsaechlich dazu fuehrte, dass die Schleife nich verifizierbar war. Er wurde dann in einem Paper publiziert und seit dem glaubt man das einfach.

Jester

Apollon schrieb:

Ueberhaupt gehe ich davon aus, dass irgendwannmal irgendjemand einen Fall gefunden hat, wo break tatsaechlich dazu fuehrte, dass die Schleife nich verifizierbar war. Er wurde dann in einem Paper publiziert und seit dem glaubt man das einfach.

Daran glaube ich eher nicht. Ich sehe keinen Grund, warum man die Nachbedingung nicht auch so formulieren können sollte, dass sie auch im break-Fall korrekt ist.

Ob man break nun verwendet oder nicht ist mir eigentlich ebenfalls herzlich egal. Nur wenn es tatsächlich handfeste Gründe gibt es nicht zu tun, dann würde ich das gerne wissen. Deswegen frage ich hier nach.

Vielleicht solle mal jemand eine Schleife posten, die ohne "break" nicht auskommt. Deshalb denke ich mir mal schnell eine aus :

#include <stdlib.h>
#include <stdio.h>

int main ()
{
 randomize ();

 int i;

 for ( i = 0; i < 100; i++ ) {

  if ( (rand () % 100) > 90 ) break;

  printf("%d ", i);

 }

 return 0;
}

Wie kann man jetzt prüfen, ob die For-Schleife von i = 0 bis i = 99 korrekt arbeitet ?

P.S.: Auskommentieren gilt nicht !

pale dog

merker schrieb:

Wie kann man jetzt prüfen, ob die For-Schleife von i = 0 bis i = 99 korrekt arbeitet ?

indem man die werte kennt, die von rand() kommen. das sind ja immer dieselben

finix

merker schrieb:

Vielleicht solle mal jemand eine Schleife posten, die ohne "break" nicht auskommt.

So eine Schleife gibt es nicht.