Ich bin neu in diesem Forum und auch neueinsteiger was C++ angeht. Mit dem Programmieren hab ich von knapp einem halben Jahr in einer Wirtschaftsinformatikschule angefangen und bin nicht sehr weit mit meinen Kenntnissen, ich bin nicht halb so weit wie die meisten von euch, und will euch erst garnicht lange belässtigen mit diesem für mich verflucht grossen, aber für euch überhaupt kein Problem1^^. Also komme ich gleich zum Problem^^

Wir haben in der Schule ein Projekt "Übungs Auftrag" das bis nächste Woche fertig sein muss, es geht darum das wir uns anstellen wie irgendwelche Profis in C++ anstellen und ein Programm mit Planung usw. erstellen. Ich habe mich entschieden ein Programm zu erstellen, desen Funktion und Aufgabe darin besteht, die grösste Zahl von 5 eingegebenen raussucht. Mein Problem jetzt, ich weiss zwar wie ich die Eingabe des Users verlangen kann und wie ich etwas ausgeben lassen kann, aber was ich nicht richtig verstehe ist das Thema mit den "for und "while" usw. schleiffen, um etwas richtiges Reissen zu können, es wäre sehr Nett wenn ihr mir helfen könntet und mir den Queltext von euch zeigen würdet. Danke im Vorraus!!.

MFG Antikoerper.K

Ein sehr guter Einstieg in das thema kontrollstrukturen.
Auch for und while schleifen werden erklärt.

Soweit ich das Thema versteh sollt ihr wie die "Profis"
euer Projekt erstmal durchplanen.
Hast du das schon gemacht?

Ich hab mal Mitleid...
Ich hock grad frustriert vor meinem Französischbuch
und kann nachvollziehen wie es ist wenn man nix blickt.

#include <iostream>
using namespace std;

#define NUM 5

int main() {

    int werte[NUM];

    cout << "Programm gestartet" << endl;

    EINGABE:
    cout << "Bitte geben sie " << NUM << " Werte ein" << endl;

    try {
        //Werte einlesen
        for(int i = 0; i < NUM; i++) {
            cin >> werte[i];
            //Ungültige Eingabe abfangen
            if(!cin.good())
                throw werte[i];
        }
    }
    //Ungültige Eingabe behandeln
    catch (int x) {
        cin.clear();
        cin.ignore(20,'\n');
        cout << "Ungültige Eingabe: " << x << endl;
        goto EINGABE;
    }

    //Sortieren nach der Größe
    for(int i = 0; i < NUM-1; i++) {
        for(int j = i+1; j < NUM; j++) {
            if(werte[i] <= werte[j])
                continue;
            int cache = werte[i];
            werte[i] = werte[j];
            werte[j] = cache;
        }
    }

    //Ausgabe
    cout << "Ihre " << NUM << " eingegebenen Werte der Größe nach sortiert" << endl;
    for(int i = 0; i < NUM; i++) {
        cout << werte[i] << " ";
    }
    cout << endl;

    cout << "Programm beendet!" << endl;
    return 0;
}

Also als Wirtschaftsinformatiker solltest du doch google und so weiter kennen.

chrische

goto, dass ist aber extrem hässlicher Programmierstil, bitte keinem Anfänger sowas angewöhnen

Das ist immer irgendwie die Standardantwort, wenn irgendwer in irgendeinem Quellcode "goto" liest.
Fakt ist aber IMHO, dass es manchmal einfach sauberer ist ein goto zu benutzen, vor allem, wenn es um so simple Sachen wie Zahlen sortieren geht. Klar gibt es auch ein dutzend andere Ansätze, wie man obiges Problem lösen kann, aber ein einziges! goto tut hier keinem Weh.

Und im übrigen: Wenn es so wahnsinnig schlimm und schlecht ist, mal goto zu benutzen, warum wird es dann nicht einfach vom offiziellem C++-Komitee als deprecated eingestuft?

bool falseInput;
do {
    falseInput = false;
    cout << "Bitte geben sie " << NUM << " Werte ein" << endl;

    try {
        //Werte einlesen
        for(int i = 0; i < NUM; i++) {
            cin >> werte[i];
            //Ungültige Eingabe abfangen
            if(!cin.good())
                throw werte[i];
        }
    }
    //Ungültige Eingabe behandeln
    catch (int x) {
        cin.clear();
        cin.ignore(20,'\n');
        cout << "Ungültige Eingabe: " << x << endl;
        falseInput = true;
    }
} while(falseInput);

Greetz

Fakt ist aber IMHO, dass es manchmal einfach sauberer ist ein goto zu benutzen, vor allem, wenn es um so simple Sachen wie Zahlen sortieren geht.

Das ist schlichtweg falsch. Und selbst wenn es richtig wäre, müsste diese Behauptung immernoch bewiesen werden.

was ist goto?? noch nie gehört;)

Sieht man doch oben. Es springt zu einer angegebenen (Sprung-)Marke.

Greetz

Greetz

Ja schon. Man sollte es aber zumindest kennen bzw. verstanden haben. ...

"Ironie" bedeutet in diesem Zusammenhang, dass Boris durchaus "goto" kannte, wohl auch verstanden hat ....

Gruß,

Simon2.

Greetz

Goto is schick,. in asm wird andauernd jmp benutzt,.. warum net in c/c++, vb, tp, etc... ??? mal ehrlich es is schnell, richtig angewendet isses sauber, und frisst wenig speicher,...
mfg zeusi

Goto is schick,. in asm wird andauernd jmp benutzt,.. warum net in c/c++, vb, tp, etc... ??? mal ehrlich es is schnell, richtig angewendet isses sauber, und frisst wenig speicher,...

Also, entweder bist Du ein Troll oder Du hast keine Ahnung.

Goto is schick,. in asm wird andauernd jmp benutzt,.. warum net in c/c++, vb, tp, etc... ??? mal ehrlich es is schnell, richtig angewendet isses sauber, und frisst wenig speicher,...
mfg zeusi

Naja, Assembler hat auch nicht so viele Schleifenkonstrukte (außer loop und die Befehle zur Stringverarbeitung fallen mir grad keine ein) und auch kein if-then-else (nur wenige Implementierungen zumindest). Da hast du wenig Möglichkeiten um jmp wegzubekommen. Aber in C++ würde ich es nicht bevorzugen, es macht die Lesbarkeit der Programme schwerer und bei großen Programmen kann sowas sehr unübersichtlich werden. In Assembler passt sowas auch rein, aber es passt weniger gut in höhere Programmiersprachen. Und ob ich jetzt eine Variable einsetze und Abfrage oder mit einem goto springe wird mein Programm nicht wesentlich schneller machen. Ich finde es besser als eine Exception zu werfen (was ja auch gerne gemacht wird). Man sollte aber nicht an so unnützlichen Stellen optimieren die nicht relevant sind. Ich glaube nen Byte haben die meisten Systeme noch frei für ein Flag. Und dann hat man doch wesentlich lieber eine gute Übersicht, als ein Programm was 2 Takte schneller läuft.

Eventuell sollte diese Diskussion zu goto lieber abgetrennt werden von diesem Topic.

Greetz

Zu meiner Zeit als Azubi fand ich immer diese verschachtelungen schlimm:

if(resoruceA ok)
{
     if(resourceB ok)
     {
          if(resourceC ok)
          {
              if(resourceD ok)
              {
                  if(resourceE ok)
                  {
                     // Mit den Resourcen arbeiten (irgendwo jenseits der 30 Spalten)
                     RäumeE auf
                  }
                  Räume D auf
              }
              Räume C auf
         }
         Räume B auf
     }
     Räume A auf
}

Das wollte ich nicht, also kam man zu einem;

if(!Resource A ok)
   {
      return;
   }

   if(!Resource B ok)
   {
      Raeume A auf;
      return;
   }

   if(!Resource C ok)
   {
      Raeume A auf;
      Raeume B auf;
      return;
   }

   if(!Resource D ok)
   {
      Raeume A auf;
      Raeume B auf;
      Raeume C auf;
      return;
   }

   if(!Resource E ok)
   {
      Raeume A auf;
      Raeume B auf;
      Raeume C auf;
      Raeume D auf;
      return;
   }

    // Mit Resourcen arbeiten

      Raeume A auf;
      Raeume B auf;
      Raeume C auf;
      Raeume D auf;
      Raeume E auf;

//    [...]

Damit war ich diese schleifen los aber wehe es kommt eine neue Resource dazu - wer denkt schon daran die überall einzutragen ?

Also noch schlimmer als die Schleifen und noch schwerer zu lesen.

Ich hab dann liebendgerne einfach mit einer Sprungmarke gearbeitet:

if(!Resource A ok)
      goto cleanup;

   if(!ResourceB ok)
      goto cleanup;

   if(!ResourceC ok)
      goto cleanup;

    if(!RecourceD ok)
      goto cleanup;

    if(!RecourceE ok)
      goto cleanup;

   // Mit den Resourcen arbeiten

cleanup:
    if(ResourceA ok)
       Räume A auf

    if(ResourceB ok)
       Räume B auf

    if(ResourceC ok)
       Räume C auf

    if(ResourceD ok)
       Räume D auf

    if(ResourceE ok)
       Räume E auf

}

Da war ich damals unheimlich stolz drauf, weil man einfach den Quellcode lesen konnte und sich nicht durch mehrfach verschatelte IFs hangeln musste.

War man am eigentlichen Quellcode angelangt, konnte man sichergehen das alles geklappt hatte, musste nicht im Editor Scrollen und konnte einfach alles was zum Aufräumen benötigt wird ans Ende stellen.

Ausnahmen bei der Bereinigung waren einfacher zu lesen und waren nicht irgendwo im Schleifenchaos untergebracht. Man sah einfach das aufgeräumt wurde und wie.

Bis auf einen Kollegen konnten sich damit anfreunden und die Pflege war einfacher. Aber dann geschah das schlimme, jemand setzte etwas Aufräumarbeit nicht hinter der Sprungmarke fort sondern klatschte die irgendwo anderst hin. Es gab für mich einfach keine Chance das zu erzwingen.

Dann durfte ich C++ Programmieren und der Vorgesetzte musste mit ziehen. Ich konnte diesen dann Zwingen bestimmte Regeln einzuhalten , was mir mit dem goto nicht Möglich war. Aufräumarbeiten konnten in Destruktoren gepackt werden etc.

Sobald man also ein goto im Quellcode geschrieben hat, sollte man überlegen, ob das die richrige Lösung ist. Allerdings sollte man auch nie vergessen, das man einen gewissen Aufwand/Nutzen ziehen muss. An manchen stellen ist ein goto nicht verherend aber wirtschaftlicher , vorallem wenn man unter Zeitdruck fremden Code umbauen müsste um die gotos los zu werden.

Ein goto kann also gerechtfertig sein, aber ich denke man kann sich vllt. darauf einigen, das C++ ausreichend Möglichkeiten bietet die Probleme die man mit goto umgehen will viel eleganter zu lösen.

In neuen Projekten also hat man immer die Möglichkeit das passend zu bauen

NewProggie schrieb:

Fakt ist aber IMHO, dass es manchmal einfach sauberer ist ein goto zu benutzen, vor allem, wenn es um so simple Sachen wie Zahlen sortieren geht.

Das ist schlichtweg falsch. Und selbst wenn es richtig wäre, müsste diese Behauptung immernoch bewiesen werden.

Das goto in dem Beispiel ist grauselig, jawoll, weil es die "goldene goto Regel" verletzt: "springe immer nur nach links und nach unten". Die 2. wichtige Regel, "springe niemals über initialisierungen", erzwingt VC ja soweit ich mich erinnere.

Wenn man es so einsetzt sehe ich kein grosses Problem, und es kann wunder an Übersichtlichkeit tun, wenn man aus irgendeinem Grund keine Exceptions verwendet, aber trotzdem brav error-handling & cleanup Code schreibt. Ein "finally" statement würde hier helfen, gibts aber leider auch nicht. Böh

Mit Exceptions hab' ich goto kaum mehr verwendet, aber selbst dann noch ab und zu, wenn ich aus verschachtelten Schleifen "braken" möchte, und ohne goto ne zusätzliche Variable bräuchte. State ist eben ein notwendiges Übel, und ich will nicht noch mehr State haben als ich muss, dann lieber goto
Wenn es in C++ ein "break N" statement (bzw. "named loops" und ein "named break" statement) gäbe, könnte ich bei Exception-freiem Code ganz darauf verzichten.

goto ist IMHO sehr "C++ig", wenn man weiss was man tut soll mans nehmen, sonst sollte man lieber gleich die Finger von C++ lassen.

Ein "finally" statement würde hier helfen, gibts aber leider auch nicht. Böh

Braucht man doch auch nicht. Müll wird am Ende eines Blocks doch sowieso weggeräumt, auch wenn's Fehler gab -- solange der Fehler nur irgendwann gefangen wird:

struct Foo { ~Foo() { cout << "~Foo" << endl; } };

int main()
{
    try {
        Foo x;
        throw "abcdefg";
    }
    catch (...) { cout << "catch" << endl; }
    cout << "Left block" << endl;
}

Ausgabe:

~Foo
catch
Left block

D.h. 'finally' wird durch die Kapselung von Ressourcen in Klassen ersetzt. RAII ist IMHO einfach mächtiger. Und zwar so mächtig, dass Microsoft in .NET über den "disposable pattern" eine abgespeckte Version von RAII eingeführt hat und dafür sowohl in VB als auch in C# sogar syntaktischen Zucker für eingeführt hat, den 'Using'-Block, der mir in seiner Benutzung doch seehr C++-ig anmutet.

Ein goto ist z.B gut, um aus einer inneren Schleife bei mehrfach verschachtelten Schleifen voll auszusteigen - also wo break es nicht schaffen kann - auch die äusseren Schleifen zu beenden....

Auch wenn es ebenfalls "suboptimal" wäre, würde ich bei sowas (wenn es wirklich nicht anders geht) immer noch lieber exceptions werfen...
Und Makros sind eine echte Pest.
Wie hieß es so schön: "...nur wenn man den Rücken an der Wand hat ... und ein Messer am Hals.... ein sehr, sehr scharfes Messer !"

Ist "finally" nicht nur eine Krücke, die man braucht, weil man in Java keine Destruktoren hat ?

Gruß,

Simon2.

#include <iostream>
#include <iterator>     // istream_iterator
#include <algorithm>    // max_element

int main()
{
    using namespace std;
    cout << "Bitte einige Zahlen eingeben. Dies Programm bestimmt die groesste. \nBeenden Sie die Eingabe mit einem 'q' ..." << endl;
    istream_iterator< double > i = max_element( istream_iterator< double >( cin ), istream_iterator< double >() );
    if( i != istream_iterator< double >() )
        cout << "Die groesste Zahl Ihrer Eingabe ist: " << *i << endl;
    return 0;
}

Gruß Werner :xmas2:

Eine Lösung ohne Iteratoren:

int max_val,val;
while(cin>>val)
  if(val>max_val) max_val=val;
cout<<"größter Wert war:"<<max_val<<endl;

Zur goto-Diskussion: Ja, goto sollte man kennen. Aber bevor man es einsetzt, sollte man überprüfen, ob man Alternativen hat (und Exceptions sind imho genauso ungeeignet für "reguläre" Programmabläufe).

Aber bevor man es einsetzt, sollte man überprüfen, ob man Alternativen hat (und Exceptions sind imho genauso ungeeignet für "reguläre" Programmabläufe).

Was spricht denn jetzt bitte gegen Ausnahmen? Und wieso "genauso" ungeeignet? 'goto' ist deswegen ungeeignet, weil es nicht strukturgebunden ist und somit die Programmstruktur zerstört, das ist bei Ausnahmen nicht der Fall.
Und wieso "bevor man sie einsetzt"? Welches Einsatzgebiet (außer eventuell dem Verlassen verschachtelter Schleifen) hat 'goto' denn?