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

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.

Apollon

merker schrieb:

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

Ich habe sie mal ein wenig modifiziert.

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

int main ()
{
 randomize ();

 int i;

 for ( i = 0; i < 100 && rand() % 100 > 90; i++ ) {

  printf("%d ", i);

 }

 return 0;
}

Wie finix bereits sagte, solch eine Schleife existiert nicht.

Ähem, vielen Dank für die Antworten.

Ich wollte mit meiner Schleife nur folgendes klarmachen :

Schleifen mit mehr als einer Laufbedingung sind nicht validierbar !

Deshalb erübrigt sich die Frage, ob man eine Schleife mit "break" verlassen darf oder ob man besser den "Schleifenkörper :-)" umformuliert.

pale dog

merker schrieb:

Schleifen mit mehr als einer Laufbedingung sind nicht validierbar !

und warum nicht?

Weil die Laufbedingungen voneinander unabhängig sind obwohl sie zusammen eine Schleife (Einheit, Kontrollstruktur) bilden.

Würde man zu "Testzwecken" eine oder mehrere Laufbedingungen auskommentieren, würde man "irgendwas" aber nicht die Schleife testen.

Simon2

EDIT: Hat Apollon schon gemacht.