for(;;) schleife verlassen

[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 ^^

[volkard]

PAD schrieb:

@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.

glaub ich nicht.

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

definitiv falsch.

Jetzt zum Destruktor
Laut Definition ist der Destruktor das Gegenstück zum Konstruktor

definitiv falsch.

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.

darum geht es nicht.

Deinen heisgeliebten Konstruktor kann man da ja wohl nicht verwenden.
Somit ist man bei einer break oder Flag Lösung.

natürlich kann man.

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

nonsense.

Für mich ist da kein Unterschied, außer das ich ein anderes Konzept angewendet habe.

du hast keine ahnung, was exceptionsicherheit bedeuten soll.

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.

der hauptunterschied ist, daß du noch nichtmal "effektiv c++ programmieren" gelesen und kapiert hast. das ist oberpeinlich, wenn man so redet, wie du.

ich will hier definitiv niemand etwas aufdrängen, sondern ich nutze Beispiel aus meiner Arbeit um anderen zu helfen

du hilfst damit aber keinem. im gegenteil. bitte stelle diesbezügliche aktivitäten ein, bist du "effektiv c++ programmieren" und am besten auch noch "exceptional c++" kapiert hast.

oder von anderen durch gut Argumente was zu lernen.

offensichtlich bist du lernbefreit.

Uberzeugen kann man mich gerne, Uberreden nicht.

nein, du bist nicht bereit, argumente, und seien sie noch so scharf ziehend, anzunehmen.

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.

glaub mir, ich kenne die syntax der schleifen und von switch.

[volkard]

PAD schrieb:

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; 
}

humbug.
wie fast immer ist die einfache version die gute. die folgende ist zu deinem müll funktional identisch:

func1(...) 
{ 
  for (a;b;c) 
    if (condition) 
     return 33; 
 ..... 
 return PASS;
}

es geht darum, zu erlauben, daß die funktionen, die man selber aufruft, exceptions werfen, und zwar wo sie wollen. und darum, nicht try/catch schreiben zu müssen, außer man will wirklich den fehler bearbeiten und nicht nur, um was aufzuräumen.

[PAD]

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

definitiv falsch.

C++ bietet keine zusätzlichen Methoden an, komisch jedes Buch schreibt aber das Gegenteil
Falsch sagen kann jeder Ich sprach von Überzeugen nicht von über reden.
Bring ein Beispiel

Jetzt zum Destruktor
Laut Definition ist der Destruktor das Gegenstück zum Konstruktor

definitiv falsch.

Das Stoustrup was falsches schreibt wundert mich Gleiche Quelle Kapitel 10.4.1

Nächste 2 Zitate, wenns dir nicht in de Kram passts wirds ignoriert Überzeugen nicht überreden wo ist das Beispiel

In dem Beispiel, falls ein Fehler drin ist zeigen, oder Bessere Lösung vorschlagen Nonsens ist geniale Hilfe

du hast keine ahnung, was exceptionsicherheit bedeuten soll.

Un du bist nicht in der Lage das zu erklären.

Wenn ich im Stoustrup mir Kapitel E.2 anschaue erfüllt mein C Code die Bedingung die exceptionsicherheit gestellt wird ohne c++ zu benutzen.

Stoustrup ist mir neben dem Standard für Definitionen lieber.
Ich benutze lieber die Quelle als den von vielen gefilterten Aufguss.
Was nicht heist das andere Leute keine guten Bücher schreiben

lernbefreit: Was dich nicht wundern sollte, ich will überzeugt werden nicht überredet, und bisher keine sinnvollen Argumente deinerseits

Wer blind antwortet ohne den Text zu lesen, gibt die falschen Antworten.

:p Zusammenfassung deine Antwort ohne ein sinnvolles Argument eigentlich Schade :p

[PAD]

@volkhard

Sorry du hast mit den Exceptions angefangen und du hast nicht begriffen das vor dem return noch weitere Aktionen waren
die ausgeführt werden sollten bevor die Funktion verlassen wird.

[HumeSikkins]

PAD schrieb:

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

definitiv falsch.

C++ bietet keine zusätzlichen Methoden an, komisch jedes Buch schreibt aber das Gegenteil

Und das sind genau die Sätze mit denen man sich disqualifziert. Selbst ein halbes Pfund Rindergehacktes ist dazu in der Lage das "definitv falsch" einzuordnen. Du aber überführst es mutwillig in den falschen Kontext.
Mit etwas gutem Willen kann man zwar sagen, dass C++ zusätzliche Möglichkeiten
gegenüber C bietet. Die Auusage "Jedes C-Programm ist auch ein C++ Programm" bleibt dadurch aber nach wie vor "definitv falsch".
Jedes heißt: Gegenbeweis durch Beispiel möglich:

#include <stdlib.h>
int main()
{
char* p = malloc(1);
free(p);
return 0;
}

Ups. Schon fertig. Gültiges C89/C99 nicht aber gültiges C++.