Problem mit jumpen

elise

und zur prüfung von falscheingaben bietet sich folgendes konstrukt sinniger an:

#include <climits>//für INT_MAX

int main( )
{
    int x;

	while ( !(cin>>x) ) {

		cin.clear();
		cin.ignore(INT_MAX, '\n');
		cout<<"Falscheingabe";
	}
}

net 0

Darthshoot2 schrieb:

switch (Zahl1) 
   { 
   case ('a'): 
   case ('b'): 
   case ('c'): 
   case ('d'): 
   case ('e'): 
   case ('f'): 
   case ('g'): 
   case ('h'): 
   case ('i'): 
   case ('j'): 
   case ('k'): 
   case ('l'): 
   case ('m'): 
   case ('n'): 
   case ('o'): 
   case ('p'): 
   case ('q'): 
   case ('r'): 
   case ('s'): 
   case ('t'): 
   case ('u'): 
   case ('v'): 
   case ('w'): 
   case ('x'): 
   case ('y'): 
   case ('z'): 
   // Erweiterte Zeichen bei deutschen Keyboards 
   case ('ö'): 
   case ('ü'): 
   case ('ä'): 
      { 
         cout << "Falsche Eingabe der Zahl!\n"; 
         // Neu eingeben... 
         goto Zahlen_Eingabe1; 
      } break; 
   }

sowas könnteste auch kürzer schreiben:
if (!isdigit(Zahl1)) goto Zahlen_Eingabe1;

Darthshoot2 -_-

Hmmm ich bin noch net bei For und While Schleifen.. hmm also ich werds umbauen, sobald ich da bin, aber warum kommt denn da so ein komischer Fehler?
Ich meine die Eingabe und Auswertung ob was falsch war unterscheidet sich 0 von der Eingabe und Auswertung der Zeichen und da klappt alles

Kann mir einer sagen wie ich das mit Switch hinbekomme?
Das wäre klasse, weil ich denke das ich da noch länger net hinkommen werde..

@Net: He kannste mir diesen Command mal genauer erklären?

groovemaster

Whoa, also für das, was du machen willst, wäre mir der gepostete Code schon zu lang. Und wenn das nur 2/10 sind...
Nichts für ungut, du solltest aber deinen Stil auf jeden Fall nochmal überdenken.

Auch habe ich deinen Quellcode jetzt nicht im Detail angeschaut, aber du machst einen logischen Fehler. Erstmal liest du eine Ganzzahl ein:

cin  >> Zahl1;

Das ist ja noch ok. Aber dann vergleichst du diese Eingabe mit Buchstaben. Das funktioniet zwar (Zeichenliterale evaluieren ja letztendlich auch nur zu integralen Werten), ist aber logisch vollkommen falsch. Du liest ja bereits einen integralen Wert ein (Typ int), dh cin sorgt schon selbst dafür, dass auch nur gültige Ziffern für diesen Wert in Betracht gezogen werden. Evtl. Fehler kannst du wie folgt abfragen:

if (!(cin >> Zahl1))
    // Fehler

IIRC gabs da aber noch etwas, was hierdurch nicht abgefangen wird. Ist mir momentan allerdings entfallen. Spielt für deine Anwendunge auch erstmal keine Rolle.

Ausserdem ist dein Programm ein nettes Beispiel für den Einsatz des Strategy Patterns.

case ('+'):
      {
         // Manmanman... ganz schön klever
         Ergebnis = Zahl1 + Zahl2;
         cout << "1. Das Ergebnis lautet --> " << Ergebnis << endl;
      } break;
      // War es Minus?
   case ('-'):
      {
         // Jetzt wird minus gerechnet
         Ergebnis = Zahl1 - Zahl2;
         cout << "1. Das Ergebnis lautet --> " << Ergebnis << endl;
      } break;
      // War es Plus?
   case ('*'):
      {
         // Hmmm das multiplizieren ist einfach
         Ergebnis = Zahl1 * Zahl2;
         cout << "1. Das Ergebnis lautet --> " << Ergebnis << endl;
      } break;
      // Und jetzt nur noch dividieren
   case (':'):
      {
         // Jetzt wird minus gerechnet
         Ergebnis = Zahl1 / Zahl2;
         cout << "1. Das Ergebnis lautet --> " << Ergebnis << endl;
      } break;
   }

Merkst du was? Sehr viel identischer Code. Das ist nicht nur redundant (auch wenn der Compiler da noch ein bisschen optimieren kann, zB die String Literale), sondern führt auch schnell zu Inkonsistenzen. Lagere einfach die unterschiedlichen Sachen in eine Strategy Klasse/Funktion aus und du hast schon mal ein Stückchen zur Vereinfachung des Quellcodes beigetragen, zB

struct calc_strategy
{
    static int make_it_so(char op, int lhs, int rhs)
    {
        switch (op)
        {
            case '+':
                return lhs + rhs;
            case '-':
                return lhs - rhs;
            case '*':
                return lhs * rhs;
            // solltest du nicht besser '/' verwenden?
            case ':':
                return lhs / rhs;
        }
        // Fehler!?
        return 0;
    }
};

Ergebnis = calc_strategy::make_it_so(chZeichen1, Zahl1, Zahl2);
cout << "1. Das Ergebnis lautet --> " << Ergebnis << endl;

Ist natürlich noch relativ einfach gehalten und lässt sich verbessern und mit anderen Teilen deines Programmes verbinden. Soll daher nur das Prinzip verdeutlichen.

Und bitte bitte bitte bitte bitte lass diese Verwendung von goto schnell in der Versenkung verschwinden und benutze für sowas vorgesehene Kontrollstrukturen wie Schleifen.

net 0

Darthshoot2 schrieb:

@Net: He kannste mir diesen Command mal genauer erklären?

vergiss es einfach. das geht nicht bei dir weil du einen 'int' eingibst (hatte groovy schon drauf hingewiesen).

Diese Art der Programmierung mit gotos nennt man zu recht auch Spaghettiprogrammierung. Drucke doch spaßeshalber mal den Quelltext aus und simuliere den Ablauf des Programms, indem du mit einem Bleistift den Verlauf nachzeichnest. Schnell wirst du (hoffentlich) feststellen, dass es ziemlich chaotisch wird und einem Teller Spaghetti ähnelt.

Das Programm was du dort geschrieben hast ist erst eine sehr kleine Applikation. Nun stell dir einfach mal vor, du programmierst an einem großen Projekt und verwendest permanent diese scheußlichen gotos...

Ich habe mich sehr intensiv mit der OOA/D beschäftigt und programmiere schon länger in C++; da muss ich sagen ich habe in einem ernsthafen Programm noch _nie_ gotos verwendet - noch nicht mal ein einziges! Wenn du mein Tipp hören möchtest: Vergiss die gotos einfach. Wenn die in deinem Buch vorkommen, dann überspring das Kapitel einfach oder kauf dir ein anständiges Buch. Du kannst ja mal in ein Programm das dir gefällt reinschauen (ein vorteil von opensource) und mal nach gotos suchen - ich wette du wirst keine oder (je nach Anwendung) nur einige wenige finden.

otze

vermutung1: der threadersteller hat noch nix von schleifen gehört
vermutung2: das strategy pattern wird er nicht verstehen[, weil]
vermutung3: er hat erst grad mit der programmierung angefangen
vermutung4: er sollte sich an ein gutes tutorial seiner wahl wenden

net 0

otze schrieb:

vermutung2: das strategy pattern wird er nicht verstehen[, weil]

groovy hat's doch gut erklärt da oben

otze

net schrieb:

otze schrieb:

vermutung2: das strategy pattern wird er nicht verstehen[, weil]

groovy hat's doch gut erklärt da oben

hast du schonmal ein Haus auf Sand gebaut?

groovemaster

otze schrieb:

vermutung2: das strategy pattern wird er nicht verstehen[, weil]

Ja, das mag gut sein. Nur wollte ich auch nicht unbedingt, dass er es versteht. Strategy hat ja auch nicht Code Simplification als Hauptziel, das ist eigentlich nur ein schöner Nebeneffekt. Ich wollte dem OP einfach nur eine Möglichkeit zeigen, wie er seinen Code vereinfachen kann, da er doch so einiges unnötig mehrfach macht. Ich kann mich noch recht gut an meine ersten Gehversuche in Pascal erinnern. Mich hat es einfach immer gestört, wenn ich solche Codeduplikate hatte, wo nur 1-2 Unterschiede jeweils drin waren. Dann dieses ganze Copy&Paste, danach die einzelnen Stellen anpassen. Da haben sich schon mal schnell Fehler eingeschlichen. Und all das, nur weil man es nicht besser wusste. Der OP braucht das Strategy Pattern ja gar nicht zu kennen (ist ja auch ein recht umfangreiches Thema - und wie du schon sagst, für einen Anfänger noch zu viel), aber er soll zumindest das Prinzip des Stück Codes verstehen, was ich ihm gepostet habe, um damit problemlos auch die anderen Teile seines Programmes vereinfachen oder flexibler gestalten zu können.

net 0

groovemaster schrieb:

Ich kann mich noch recht gut an meine ersten Gehversuche in Pascal erinnern. Mich hat es einfach immer gestört, wenn ich solche Codeduplikate hatte, wo nur 1-2 Unterschiede jeweils drin waren.

das stört wohl viele aber manchmal geht's nicht anders. angenommen man hat 'nen code der echt schnell sein muss in der ausführung (jeder taktzyklus zählt). der code hat 'ne schleife in derem innern eine bedingung ist. un das ganze schneller zu machen kann man die bedingung aus der schleife rausnehmen und zwei schleifen schreiben die sich sehr ähnlich sind.
also sowas:

while (...)
{
  mach_immer();
  if (dedingung)
    mach_dies();
  else
    mach_das();
}

ist langsamer als

if (bedingung)
  while (...)
  {
    mach_immer();
    mach_dies();
  }
else
  while (...)
  {
    mach_immer();
    mach_das();
  }

C.Santa

net schrieb:

otze schrieb:

vermutung2: das strategy pattern wird er nicht verstehen[, weil]

groovy hat's doch gut erklärt da oben

Strategy Pattern? Wo?