for(;;) schleife verlassen

[PAD]

@Volkhard Beitrag von 23:28

Sowohl Lösung a als auch lösung b haben ihre Berechtigung.
Ich würde allerdings die Schleife nur bis kanditat/2 laufen lassen, Spart ne masse Zeit.
Aufräumarbeiten sind nicht nur Dinge die durch Destruktoren erledigt werden können, es können auch
längere CodeSequencen sein, die sich mit ganz anderen Dingen beschäftigen (siehe Hardwarenahe Programmierung, Schnittstellen unminitialiseren so daß ich gar keine Destructor brauche) .
Diese Teile von Code könnte man auch unmittelbar ins if schreiben, was aber die Lesbarkeit nicht unbedingt fördert.

solltest einfach meine argumente verstehen und mir zustimmen.

Überzeugen ist besser als Überreden

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen

Mein Bezug zu Basic bezog sich auf die Vergangenheit, diese Art von Basic Compileren/Interpretern kennen die meisten Leute heute nicht mehr. Die "moderenen" Compiler haben bei sovielen guten Sprachen geräubert das es jetzt etwas ganz anderes geworden ist (blos was).
Nur der Name ist geblieben, weil jeder meint in Basic kann ja auch ich programmiern, Hochsprachen I´gitt ba Pfui viel zu kompliziert.

[AndreasD]

Also ich muß Euch eines sagen. Ich hatte vor einiger Zeit mal im BCB-Teil gepostet, daß ich am Anfang einer Methode Prüfungen mache und wenn etwas nicht stimmt bzw. die Methode einfach aufhören soll (sei's, um eine Fehlerkennung ohne Exception zurückzugeben oder um einen im konkreten Fall sinnlosen/unnötigen Aufruf der Methode zu unterbinden), dann springe ich mit einem return gleich zu Beginn aus der Methode raus. Jansen warf mir dort einen Verstoß gegen die sp vor. Das sah ich aber nicht so, weil es für mich eindeutiger ist, daß ich aufhöre und nicht noch 20 Hilfsflags definiere und 30 if-Abfragen einbaue, die dann ein nettes eingerücke geben und man dann gar nicht mehr weiß, wann man durch welche Bedingung durchläuft (stark übertrieben).

Aber gegen ein break in einer längeren for-Sequenz hab ich auch nichts. Wieso sollte ich diese Technik des Schleifenausbruchs verhindern? Wenn ich ein break lese, weiß ich, daß der aus einer switch oder der innersten do/while/for Schleife ausbricht und gut ist. Ein klein bissel Vernunft darf ich ja von anderen Programmierern erwarten, wenn sie sowas lesen. Da ich zusätzlich auch überwiegend kommentiere, was sich tut, ist's sowieso kein Thema.

Zum Thema Endlosschleife möchte ich gestehen, daß ich auch eher zur while-Konstruktion tendiere, wobei man auch genausogut for(;;) nehmen kann. Für mich ist das eine aber so gut oder so schlecht wie das andere. Die Sprache gibt es mir in die Hand und ich kann doch selber entscheiden, wie ich das anwende. Ob das nun von C, Basic, PL1, Pascal oder was auch immer entlehnt ist, ist mir in dem Fall aber grad wurscht. Man muß ja auch nicht alles zutiefst hinterfragen und regeln. Ich sehe da keinen besonderen Sinn drin. Da gibt es sicherlich andere Dinge, über die man sich streiten kann.

[PAD]

@JFK Ist deine Signatur ein Hinweis auf OOP, ganz schön hintersinnig

Was man heute noch nicht weiß,
ist übermorgen möglicherweise schon
total veraltet...

Ich arbeite in der Testgeräteprogrammierung.
Bei uns ist es eine feste Regel daszu erst alle Parameter ausgewertet und überprüft werden, und nur wenn sie alle
richtig sind finden irgendwelche Aktioenen statt. (Also genauso wie du es auch machst)

func1(...)
{
//Auswerten überprüfen
for (a;b;c)
{
  if (error)
   ErrorCode=33;
   flag=FAIL;
   break;
}
.....

 if (PASS != flag)
   return ErrorCode;

//jetzt Settings verändern und Hardware ansprechen

....
return PASS;
}

Da ist mir auch ein Verstoß gegen sp, oop oder ähnliches völlig egal

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen, das Beste wird genommen

Das ich damit natürlich an der Uni mit den jeweiligen Gurus/Dozenten im Clinch liege ist mir klar. Aber mein Studium habe ich vor
Jahren erfolgreich beendet und arbeite jetzt in der industriellen Realität

[Bashar]

JFK: Da hatte Jansen auch Recht. Die Frage ist, ob das relevant ist. Strukturierte Programmierung ist im wesentlichen ein Dogma, das Programme fordert, die sich durch Struktogramme darstellen lassen. Das bedeutet im Einzelnen mindestens:

• es gibt nur Sequenz, einseitige, zweiseitige, mehrseitige Auswahl, kopfgesteuerte und fußgesteuerte Schleife (auch eine in der Mitte abgebrochene Schleife, die allerdings meistens verschwiegen wird, weil Pascal sowas nicht hat)
• d.h. kein goto
• jeder Anweisungsblock hat nur einen Eingang und nur einen Ausgang

Das mag vor 30 Jahren wirklich sinnvoll gewesen sein. Aber wie gesagt, es ist ein Dogma. Das eigentliche Ziel war, die Verständlichkeit von Programmen zu verbessern. Wenn das Ziel auch ohne SP erreicht werden kann, warum nicht?

Man sollte dabei z.B. bedenken, dass Exceptions nach der strukturierten Programmierung verboten sind, da sie zu zusätzlichen Ausstiegspunkten führen.

[AndreasD]

Ist richtig, was Du sagst. Und deshalb kann ich nur PAD zitieren:

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen, das Beste wird genommen

Das ich damit natürlich an der Uni mit den jeweiligen Gurus/Dozenten im Clinch liege ist mir klar. Aber mein Studium habe ich vor
Jahren erfolgreich beendet und arbeite jetzt in der industriellen Realität

Dogmen haben zu Beginn ihrer Einführung etwas heilsames. Aber nach einer gewissen Zeit verlieren sie teilweise oder ganz ihre Daseinsberechtigung und es schadet nicht, diese über Bord zu werfen. Die Zeiten, wo man noch Struktogramme machte, sind in der Praxis vorbei. Oder man skizziert mit diesen Mitteln nur noch Prozesse und grobe Zusammenhänge.

Ich muß gestehen, daß ich Exceptions auch nicht so wirklich gerne mag und setze die nur dort ein, wo ich weiß, daß es schwere Probleme sind, die üblicherweise nur während der Entwicklungsphase auftreten sollten oder wenn das System ohnehin kurz vor dem Kniefall ist.
Wenn aber irgendwas nicht so klappt, wie ich das von einer Methode verlange, dann kann die ruhig einen Fehlerwert zurückgeben und ich nehme in Kauf, daß 7fach verschachtelte Funktions/Methodenaufrufe wieder rückwärts laufen. Ich empfinde das als deutlich logischer, als wenn ich eine Exception schmeiße und irgendwer wird die hoffentlich irgendwo abfangen...

Kann gut sein, daß ich nicht wirklich in C++ codiere & denke. Aber wie gesagt: wenn etwas verständlich und fachlich richtig ist, so wie es ist, dann bin ich auf jeden Fall dafür, daß so zu machen.

Aber ich schweife wieder mal ab....

[crass]

for und while waren bei ihrer Erfindung schätz ich mal beide nicht dafür gedacht sie als Endlosschleifen zu verwenden. Schleifen die nicht gleich sagen, wo sie mal aufhören sind ja böse.. es is ja soviel feiner brav immer mit Flags zu arbeiten. Dann hat mal jemand gemerkt , daß Flags in Wirklichkeit nerven und man besser die Schleife endlos macht und sie mittendrin breakt oder returnt aber statt das mal einer auf die Idde gekommen wäre die Sprache so zu erweitern, daß es extra für diesen Zweck einen Schleifentyp gibt
zb.

loop
{
   if (irgendwas) break;
}

gibt, muß man sich halt mit billigen Tricksereien a la Parameter weglassen (for(;; ) ) oder die Weiterlauf-Bedingung immer wahr sein zu lassen, aushelfen..besser ist da imo keins davon

[HumeSikkins]

Ich muß gestehen, daß ich Exceptions auch nicht so wirklich gerne mag und setze die nur dort ein, wo ich weiß, daß es schwere Probleme sind, die üblicherweise nur während der Entwicklungsphase auftreten sollten oder wenn das System ohnehin kurz vor dem Kniefall ist.
Wenn aber irgendwas nicht so klappt, wie ich das von einer Methode verlange, dann kann die ruhig einen Fehlerwert zurückgeben und ich nehme in Kauf, daß 7fach verschachtelte Funktions/Methodenaufrufe wieder rückwärts laufen. Ich empfinde das als deutlich logischer, als wenn ich eine Exception schmeiße und irgendwer wird die hoffentlich irgendwo abfangen...

Hm, mir scheint du mißverstehst Exceptions ein wenig. Exceptions sind letztlich auch nur eine Form des "error-" bzw. "early returns". Mit dem Vorteil, dass der Fehlerpfad nicht so sehr den "normalen" Programmpfad stört. Und das sich Fehler nicht so leicht ignorieren lassen.

Wenn du folgenden Code hast (Beispiel adaptiert aus "Exception-Safety in Generic Components" von David Abrahams):

int gunc()
{
    Foo f;
    int result = f.func(); // kann werfen
    // mach was
    return result;
}

kannst du diesen natürlich auch so umschreiben, dass du keine Exceptions verwendest:

ErrorCode gunc(int& result)
{
    Foo f;
    ErrorCode e = f.func(result);
    if (e != NoError)    
        return e;
    // mach was
    return NoError;
}

Programmtechnisch macht das keinen Unterschied. Der erste Code-Schnipsel
ist aber kürzer und hübscher.

Zwar wirken Exceptions auf den ersten Blick häufig komplizierter als Fehlercodes, allein schon, weil man z.B. überall was über Exception-Safety lesen kann, nicht aber über Error-Safety. Das liegt aber nicht daran, dass Exceptions irgendwelche zusätzlichen Probleme hätten. Vielmehr ist "Exception-Safety" ein unglücklicher Name, denn die Prinzipien haben nicht direkt etwas mit Exceptions zu tun. Sie gelten eher generell. D.h. Code der sich im Falle von Exceptions nicht anständig verhält, der verhält sich auch nicht besser, wenn man alle Exceptions durch Fehlercodes ersetzt.

[THE_FreaK]

volkard schrieb:

an verschiedenen stellen kann man doch break schreiben. oder noch besser return. sehe dein problem nicht.

Klar, aber was machst du wenn du in nem case zweig bist? oder hab ich da mal wieder was programmiertechnisches verpasst? ^^#
Im Prinzip ist es doch ne geschmacksfrage, oder? beides müsste irgendwie seinen zweck erfüllen, wobei *ich* denke, das son Flag einfach besser zu erkennen ist.

[volkard]

PAD schrieb:

Aufräumarbeiten sind nicht nur Dinge die durch Destruktoren erledigt werden können, es können auch längere CodeSequencen sein, die sich mit ganz anderen Dingen beschäftigen (siehe Hardwarenahe Programmierung, Schnittstellen unminitialiseren so daß ich gar keine Destructor brauche) .

dazu sind destruktoren auch da.
was du da vor hast, wird kaputtgehen, wenn exceptions fliegen.

[volkard]

PAD schrieb:

Ich arbeite in der Testgeräteprogrammierung.
Bei uns ...

lol. der code ist ja c. fehler per errorcode statt exception. klar gehste dabei so vor wie in deinem code. dann sind auch andere regeln zum stil angesagt. andere sprache, anderer stil. ich rede von c++. dort hat man rauszuspringen, sobald ein ergebnis feststeht. c ist wirklich ne ganz andere geschichte und hat hier als argumentbringer rein gar nix verloren. und du solltest nicht den c-stil den c++-leuten aufschwätzen wollen.

[volkard]

THE_FreaK schrieb:

volkard schrieb:

an verschiedenen stellen kann man doch break schreiben. oder noch besser return. sehe dein problem nicht.

Klar, aber was machst du wenn du in nem case zweig bist? oder hab ich da mal wieder was programmiertechnisches verpasst?

offensichlich.

THE_FreaK schrieb:

Im Prinzip ist es doch ne geschmacksfrage, oder? beides müsste irgendwie seinen zweck erfüllen, wobei *ich* denke, das son Flag einfach besser zu erkennen ist.

haste den primzahlencode angeschaut und die verschiedenen versionen verglichen?
also ich hab manchmal das gefühlt, daß hier viele trolle sind. oder wollt ihr euch in eurem jugendlichen leichtsinn nur mal an mir messen?

[THE_FreaK]

volkard schrieb:

also ich hab manchmal das gefühlt, daß hier viele trolle sind. oder wollt ihr euch in eurem jugendlichen leichtsinn nur mal an mir messen?

Son quatsch! Das ich mich mit vielen von euch (inkl. dir, volkard) nicht messen kann ist mir durchaus bewusst.
Allerdings hab ich die *dumme* angewohnheit bei verständnisproblemen nachzufragen und versuche zu verstehen.

Meine Aussage ging auf sowas hinaus:

while(!end)
{
 //code
 switch(var)
 {
  case 1:
       {
         var = foo();
         break;
       }
  case 2:
       {
        vra = dumb();
        end=true;
        break;
       }

    // weiterer Code
  }
}

<- Pseudocode!
So würde ich mir helfen. das Break bezieht sich ja in diesem fall auf die switch und ein return würde das komplette prog beenden. Also wie sonnst, außer mit nem Flag? Anstatt einem offensichtlich hätte ich gern ne vernünftige antwort, auch wenns ggf. nurn schlüsselwort ist.

Aber sone Konstruktion lässt sich manchmal eben nicht ändern.
Und wie gesagt ich will mich nicht mit dir messen, weder dich hier zur weisglut treiben oder sonstiges, ich will nur verstehen und lernen.

MfG
THE_FreaK

[Bashar]

Da haste dann leider Pech gehabt. Entweder flag oder goto oder das ganze in eine Funktion und return. Zum Glück kommt sowas nicht häufig vor.

[PeterTheMaster]

ja, das ist das gleiche wie das inner loop problem. der so ziemlich einzige fall, wo goto sinnvoll ist.

[THE_FreaK]

ok, das wollt ich nur wissen, ich hadde volkard so verstanden als würde es noch ne möglichkeit geben auch in diesem fall per break oder was ähnlichem die schleife aus switch raus zu beenden.

@Bashar
Dann denk mal in die Nachrichtenschleife in der WinAPI => jedes Windoof programm auf WinAPIn basis hat sone schleife

[Bashar]

THE_Freak: öhm ja, in der Nachrichtenschleife kommt aber soweit ich weiß kein switch/case vor. Das steht dafür in der Windowprozedur, die dafür aber wieder keine Schleife ist. Worauf willst du hinaus?

[THE_FreaK]

o9k, kleiner Fehltritt, ich habs in einem OGL Tutorial gesehn, sieht da eigentlich auch ganz logisch aus.
Ich will auf nichts spezielles hinaus, es war ne reine verständnisfrage.

[PAD]

@volkard
Es ist halt so üblich das Kinder (C++) sagen alles was die Eltern (C) machen ist falsch. Das sind die Eltern auch gewöhnt.
Wenn ich mich recht erinnere steht im C++ Standard der Verweis das ihm der C Standard ein Basisdokument ist.

Jedes C-Programm ist auch ein C++ Programm
C++ bietet dazu zusätzliche Methoden und Möglichkeiten an.

Jetzt zum Destruktor
Laut Definition ist der Destruktor das Gegenstück zum Konstruktor und wird aufgerufen wenn ein Objekt zerstört wird.
Was ist bitte wenn ich das Objekt erhalten möchte und trotzdem in die obigen Situationen kommen.
Deinen heisgeliebten Konstruktor kann man da ja wohl nicht verwenden.
Somit ist man bei einer break oder Flag Lösung.

Thema Exceptions, wenn ich die von dir preferierte Methode nutze müßte es so aussehen

func1(...) 
{ 
 //Auswerten überprüfen 
 try
 {
   for (a;b;c) 
   { 
    if (condition) 
     throw 33; 
   } 
 }
 catch (int CondNum)
 {
 return Condnum;
 }

 ..... 

 return PASS;
}

func1(...) 
{ 
//Auswerten überprüfen 
for (a;b;c) 
{ 
  if (error) 
   ErrorCode=33; 
   flag=FAIL; 
   break; 
} 
 if (PASS != flag) 
   return ErrorCode; 
.... 
return PASS; 
}

Für mich ist da kein Unterschied, außer das ich ein anderes Konzept angewendet habe.
Allerdings bietet das Konzept sinnvolle Möglichkeiten die über die Fähigkeitn von C hinausgehen

Nur einfache Lösungen sind gute Lösungen und das egal woher Sie kommen, das Beste wird genommen
Das ich damit natürlich an der Uni mit den jeweiligen Gurus/Dozenten im Clinch liege ist mir klar. Aber mein Studium habe ich vor
Jahren erfolgreich beendet und arbeite jetzt in der industriellen Realität

Der deutliche Unterschied zwischen uns ist das ich bereit bin, gleichzeitig verschiedene Konzepte anzuwenden (C,C++, ...) du aber scheinbar das Glück hast nur mit einem Konzept arbeiten zu können oder zu wollen.

und du solltest nicht den c-stil den c++-leuten aufschwätzen wollen.

ich will hier definitiv niemand etwas aufdrängen, sondern ich nutze Beispiel aus meiner Arbeit um anderen zu helfen oder von anderen durch
gut Argumente was zu lernen. Uberzeugen kann man mich gerne, Uberreden nicht.

Noch ein ganz heißer Tip
Bjarne Stoustrup
Die C++ Programmiersprache
Addison Wesley
ISBN 3-8273-2058-5
4.Auflage

Lies dir Mal das Kapitel 6.1.5 durch was dort zum break geschrieben steht.

[nein]

Jedes C-Programm ist auch ein C++ Programm

Nein

[THE_FreaK]

nein schrieb:

Jedes C-Programm ist auch ein C++ Programm

Nein

Na da bin ich ja mal auf die begründung gespannt ^^