C++ Ratespiel Problem mit schleifen

**Desti123** · 08. 01. 2012, 20:37

Hi leute hab n kleines aber gravierendes Problem.
Ich geb euch einfach mal den code

Code:

#include <iostream>
#include <string>
#include <ctime>
#include <cstdlib>
using namespace std;

int main()
{
    //Treffer der farben und positionen
    int trefferFarbe;
    int trefferPosundFarbe;
    
    //Steine
    string stein1;
    string stein2;
    string stein3;
    string stein4;
    
    //Geraten
    
    string geraten1;
    string geraten2;
    string geraten3;
    string geraten4;

    
    //Stein Farben
    
    /*stein1 ="rot";
    stein2 ="blau";
    stein3 ="gelb";
    stein4 ="schwarz";
   */
   
    //Begrüßung
    
    cout << "----------------------------------"<<endl;
    cout << "                 Willkommen                " <<endl;
    cout << "----------------------------------"<<endl<<endl<<endl<<endl;
    
    //Zufallsgenerator
    time_t t;
    srand ( time(&t) );  //(srand (1) zum debuggen
    //Die ratende Kobination ausdenken
    int n,i,g,j;
    n = rand()%6 +1;
    i = rand()%6 +1;
    g = rand()%6 +1;
    j = rand()%6 +1;
    
    switch (n)
    {
           case 1: stein1 ="weiss";
           break;
           case 2: stein1 ="rot";
           break;
           case 3: stein1 ="gelb";
           break;
           case 4: stein1 ="braun";
           break;
           case 5: stein1 ="blau";
           break;
           case 6: stein1 ="schwarz";
           break;
    }
    switch (i)
    {
           case 1: stein2 ="weiss";
           break;
           case 2: stein2 ="rot";
           break;
           case 3: stein2 ="gelb";
           break;
           case 4: stein2 ="braun";
           break;
           case 5: stein2 ="blau";
           break;
           case 6: stein2 ="schwarz";
           break;
    }
    switch (g)
    {
           case 1: stein3 ="weiss";
           break;
           case 2: stein3 ="rot";
           break;
           case 3: stein3 ="gelb";
           break;
           case 4: stein3 ="braun";
           break;
           case 5: stein3 ="blau";
           break;
           case 6: stein3 ="schwarz";
           break;
    }
    switch (j)
    {
           case 1: stein4 ="weiss";
           break;
           case 2: stein4 ="rot";
           break;
           case 3: stein4 ="gelb";
           break;
           case 4: stein4 ="braun";
           break;
           case 5: stein4 ="blau";
           break;
           case 6: stein4 ="schwarz";
           break;
    }
    cout << "Wir haben vier farben w" << "\x84" << "hle klug! "<<endl <<endl;
    do 
    {
         trefferPosundFarbe = 0;
         trefferFarbe = 0;
         
    cin >> geraten1 >>  geraten2 >> geraten3 >> geraten4;
   
    bool ausgewertetS1 = false, ausgewertetS2 = false,
         ausgewertetS3 = false, ausgewertetS4 = false;
         
    bool ausgewertetG1 = false, ausgewertetG2 = false,
         ausgewertetG3 = false, ausgewertetG4 = false;
       
    if (stein1 == geraten1)
    {
               trefferPosundFarbe++;
               ausgewertetS1 = true;
               ausgewertetG1 = true;                
    }
    if (stein2 == geraten2)
    {
               trefferPosundFarbe++;
               ausgewertetS2 = true;
               ausgewertetG2 = true;
    }
    if (stein3 == geraten3)
    {
               trefferPosundFarbe++;
               ausgewertetS3 = true;
               ausgewertetG3 = true;
    }
    if (stein4 == geraten4)
    {
               trefferPosundFarbe++;
               ausgewertetS4 = true;
               ausgewertetG4 = true;
    }
    
    //Auswertung farbe stein1
    if (ausgewertetS1 == false)
    {
       if (ausgewertetG2 == false && stein1 == geraten2)
       {
                         trefferFarbe++;
                         ausgewertetS1 = true;
                         ausgewertetG2 = true;
       }
       if (ausgewertetG3 == false && stein1 == geraten3)
       {
                         trefferFarbe++;
                         ausgewertetS1 = true;
                         ausgewertetG3 = true;
       }
       if (ausgewertetG4 == false && stein1 == geraten4)
       {
                         trefferFarbe++;
                         ausgewertetS1 = true;
                         ausgewertetG4 = true;
       }
      }
      
    //Ausgewertet farbe stein2
    if (ausgewertetS2 == false)
    {
       if (ausgewertetG1 == false && stein2 == geraten1)
       {
                         trefferFarbe++;
                         ausgewertetS2 = true;
                         ausgewertetG1 = true;
       }
       if (ausgewertetG3 == false && stein2 == geraten3)
       {
                         trefferFarbe++;
                         ausgewertetS2 = true;
                         ausgewertetG3 = true;
       }
       if (ausgewertetG4 == false && stein2 == geraten4)
       {
                         trefferFarbe++;
                         ausgewertetS2 = true;
                         ausgewertetG4 = true;
       }
      }
      
      //Ausgewertet farbe stein3
    if (ausgewertetS3 == false)
    {
       if (ausgewertetG1 == false && stein3 == geraten1)
       {
                         trefferFarbe++;
                         ausgewertetS3 = true;
                         ausgewertetG1 = true;
       }
       if (ausgewertetG2 == false && stein3 == geraten2)
       {
                         trefferFarbe++;
                         ausgewertetS3 = true;
                         ausgewertetG2 = true;
       }
       if (ausgewertetG4 == false && stein1 == geraten4)
       {
                         trefferFarbe++;
                         ausgewertetS3 = true;
                         ausgewertetG4 = true;
       }
      }
      
      //Ausgewertet farbe stein4
    if (ausgewertetS4 == false)
    {
       if (ausgewertetG1 == false && stein4 == geraten1)
       {
                         trefferFarbe++;
                         ausgewertetS4 = true;
                         ausgewertetG1 = true;
       }
       if (ausgewertetG2 == false && stein4 == geraten2)
       {
                         trefferFarbe++;
                         ausgewertetS4 = true;
                         ausgewertetG2 = true;
       }
       if (ausgewertetG3 == false && stein4 == geraten3)
       {
                         trefferFarbe++;
                         ausgewertetS4 = true;
                         ausgewertetG3 = true;
       }
    }
    }
    while (trefferPosundFarbe <= 4);
    
    //Ergebniss
    if (trefferPosundFarbe == 4)
    {
                           cout <<endl << endl << endl;
                           cout << "Gl" << "\x81" << "ckwunsch du hast die Kombination eratten!" << endl << endl;
    }
    else
    {
        cout << endl;
        cout << "Treffer (Position und Farbe)= " << trefferPosundFarbe <<endl;
        cout << "Treffer              (Farbe)= " << trefferFarbe << endl;
    
    }
    system("PAUSE");
    return(0);
}

So ich weiß nur nicht wo der Fehler liegt hoffe einer von euch kann mir helfen.

**the_Night22** · 08. 01. 2012, 21:13

Da du keinen genauen Fehler genannt hast, kann ich auch nur Raten. Ich vermute aber mal, dass du das Problem meinst, das die Schleife nicht verlassen wird.

PHP-Code:


do{



}while (trefferPosundFarbe <= 4);

trefferPosundFarbe kann hier maximal 4 sein und da 4<=4 wird die Schleife nie verlassen.

mfg,
night

**stefbrot** · 09. 01. 2012, 00:11

Ja, eine Fehlerbeschreibung wäre schon ganz nützlich, wenn dir jemand helfen soll

Mal ein paar Anmerkungen:

Code:

    //Steine
    string stein1;
    string stein2;
    string stein3;
    string stein4;
    
    //Geraten
    
    string geraten1;
    string geraten2;
    string geraten3;
    string geraten4;

Hier bietet es sich an Arrays zu verwenden, anstatt 4 einzelnen Variablen, das macht die Auswertung später einfacher weil man dann Schleifen verwenden kann.

Code:

int n,i,g,j;

Wieso nimmst du hier 4 verschiedene Variablen mit irgendwelchen Buchstaben? Eigentlich brauchst du nur eine Variable, wenn du das rand() immer direkt vor dem switch machst. Un auch wenn du 4 bräuchtest solltest du die besser benennen. i und j sind üblicherweise Zählvariablen für Schleifen.
Und wenn du Tipp befolgst kannst du das switch einfach in eine Schleife tun und hast schon 40 Zeilen Code gespart.

Code:

cout << "Wir haben vier farben w" << "\x84" << "hle klug! "<<endl <<endl;

Mehr Information für den Benutzer. Welche Farben, wie muss man etwas eingeben, ...

Code:

    bool ausgewertetS1 = false, ausgewertetS2 = false,
         ausgewertetS3 = false, ausgewertetS4 = false;

    bool ausgewertetG1 = false, ausgewertetG2 = false,
         ausgewertetG3 = false, ausgewertetG4 = false;

Wieder Arrays.
Die Auswertung kann man dann auch mit Schleifen verkürzen.
Dann fehlt noch eine Ausgabe der Auswertung.
Und das was night sagt, die Schleife endet so nie.

Das sind nur ein paar Anregungen von mir, ich hoffe das hilft dir irgendwie.
mfg
stefbrot

**user710** · 17. 01. 2012, 16:24

Und denke bitte daran, dass der Computer die Rolle des Dummen und Stupiden einnimmt, aber niemals der Programmierer!

**guglmann** · 17. 01. 2012, 19:59

Zitat von stefbrot

Hier bietet es sich an Arrays zu verwenden,

Da er C++ nutzt, bietet es sich meiner Meinung nach eher an Vektoren zu verwenden. Wenn man sowieso nur "C-kompatibles C++" schreibt (cout versus printf() jetzt mal vernachlässigt), kann man das mit dem C++ auch gleich bleiben lassen...

Ansonsten stimme ich dir zu.

**blueshark27** · 18. 01. 2012, 16:22

Zitat von guglmann

Da er C++ nutzt, bietet es sich meiner Meinung nach eher an Vektoren zu verwenden. Wenn man sowieso nur "C-kompatibles C++" schreibt (cout versus printf() jetzt mal vernachlässigt), kann man das mit dem C++ auch gleich bleiben lassen...

Vektoren sind dann sinnvoll, wenn all ihre Stärken genutzt werden. Insbesondere dann, wenn sich die Größe zur Laufzeit ändern kann. Das ist hier nicht der Fall, also sollte man sich den Overhead auch gar nicht antun. Da die Vektoren mithilfe einer Baumstruktur implementiert sind, initialisieren sie immer einen zweierpotenz-großen Speicherbereich. Angenommen du benötigst einen Vektor mit fünf Elementen, dann wird für acht Elemente Speicher reserviert.

Wenn die Anzahl vorher bekannt ist und man auf stl-Container zurückgreifen möchte, so kann man eine Double ended queue verwenden. Diese hat auch einen Random-Access-Iterator und nicht den Nachteil von einem Vektor.

**Jodocus_** · 18. 01. 2012, 17:23

Oh je...

>> Vektoren sind dann sinnvoll, wenn all ihre Stärken genutzt werden.

Nein. Vektoren haben gegenüber Arrays viele Stärken, man braucht längst nicht alle, damit Vektoren trotzdem nützlicher sind als Arrays.

>> Insbesondere dann, wenn sich die Größe zur Laufzeit ändern kann.

Gerade da sind doch Vektoren nicht so Bombe, weil eine Vektor-Vergrößerung die Kopie aller Elemente nach sich zieht (genauer: Wenn der tatsächlich reservierte Bereich voll wird). Vektoren braucht man, wenn die Größe des Arrays erst zur Laufzeit fest steht und sich möglichst nicht all zu sehr ändert. Die Sache mit dem Reservierten Speicher ist gerade deshalb nur in den Vektoren vorhanden: um ein begrenztes, billiges Einfügen/Entfernen halbwegs performant und möglich zu machen, ohne dass immer sofort alles kopiert werden und Speicher angefordert/gelöscht muss oder man auf andere Container umsteigen muss, die kein Random-Access ermöglichen.

>> also sollte man sich den Overhead auch gar nicht antun.

Vektoren und Overhead? Auf kleinen Mikroprozessoren und Embedded Systems vielleicht, aber nicht an einem gewöhnlichen PC. Das kannst du nicht mal messen.

>> Da die Vektoren mithilfe einer Baumstruktur implementiert sind,

Das mag bei manchen (schlechten) Compilern so sein, in der Regel sind Vektoren intern aber dynamische Arrays. Was sie intern sind, ist prinzipiell egal, der Standard legt nur fest, dass Sachen wie Random Access klappen.

>> initialisieren sie immer einen zweierpotenz-großen Speicherbereich.

Die Größe des reservierten Speichers ist vom Standard ebensowenig vorgegeben; mag sein, dass manche Compiler dass mit 2^n handhaben. Anyway, Vektoren sind wie gesagt nicht so Bombe was das Einfügen und Entfernen von Elementen angeht, die in ihrer Anzahl verhältnismäßig groß ggü. der Initialgröße sind. Das ist beim TE aber auch nicht das Problem, weshalb sich Vektor eignet.

>> Angenommen du benötigst einen Vektor mit fünf Elementen, dann wird für acht Elemente Speicher reserviert.

Netter Versuch, stimmt aber leider nicht.

Angenommen, du benötigst einen Vektor mit 30 Elementen, dann wird für 2^30 = 1.073.741.824 Elemente Speicher reserviert.

(Wenn die Elemente 1 Byte groß wären, würde also ein 30-Byte-Vektor einen Gigabyte RAM fressen, und so schlimm ist der Overhead von Vektor natürlich nicht.)

Das 2^n kannst du dir so vorstellen: Wenn du einen Vektor hast, der 1 Element groß ist, dann wird Speicher für 2^0 * 1 = 2 Elemente reserviert. Wird dieser Speicher voll, dann wird wiederrum Speicher für 2^1 * 1 = 2 Elemente reserviert. Und dann 1 * 2^2 = 4. Und 1 * 2^3 = 8 usw. Das n in 2^n steht für die Anzahl der Speichervergrößerungen. Mathematisch ist das eine Exponentialfunktion:
ƒ(n) = a * 2^(n), wobei a die Initialgröße des Vektors ist. Ich glaube aber, dass 2^(n+1) typischer ist.

>> Wenn die Anzahl vorher bekannt ist und man auf stl-Container zurückgreifen möchte, so kann man eine Double ended queue verwenden.

Wenn die Anzahl vorher bekannt ist (vorher heißt also zur Compiletime) und sich nicht ändert, dann kann man auf std::array<N> zurückgreifen, um ein Stack-Array zu erzeugen. Das Ding kann man dann sogar für Embedded Systems benutzen und hat wiederrum viele Vorteile gegenüber gewöhnlichen Arrays. Es gibt keinen Grund, Arrays, oder C allgemein, weiterzubenutzen. Die von dir vorgeschlagene std::deque ist dafür da, Elemente performant an einem Vektor-ähnlichen Konstrukt anhängen und löschen zu können (also nur am Anfang und Ende), aber wenn es darum geht, Elemente in der Mitte einzufügen, ist der Vektor sogar immernoch performanter. Aber das will der TE doch garnicht.

**sumisumi** · 18. 01. 2012, 18:15

>> Da die Vektoren mithilfe einer Baumstruktur implementiert sind,

Das mag bei manchen (schlechten) Compilern so sein, in der Regel sind Vektoren intern aber dynamische Arrays. Was sie intern sind, ist prinzipiell egal, der Standard legt nur fest, dass Sachen wie Random Access klappen.

Was hat die Implementierung mit dem Compiler zu tun?

**Jodocus_** · 18. 01. 2012, 19:40

Sorry, das war etwas salopp. Aber oft (um nicht zu sagen meistens) liefern Compilerhersteller auch Implementierungen der Standardlibrary. Korrekterweise hätte ich das genauer unterscheiden sollen, es geht aber auf das gleiche hinaus.

**stefbrot** · 18. 01. 2012, 20:15

Zitat von Jodocus_

>> Angenommen du benötigst einen Vektor mit fünf Elementen, dann wird für acht Elemente Speicher reserviert.

Netter Versuch, stimmt aber leider nicht.

Angenommen, du benötigst einen Vektor mit 30 Elementen, dann wird für 2^30 = 1.073.741.824 Elemente Speicher reserviert.

(Wenn die Elemente 1 Byte groß wären, würde also ein 30-Byte-Vektor einen Gigabyte RAM fressen, und so schlimm ist der Overhead von Vektor natürlich nicht.)

Wie kommst du denn jetzt auf 2^30? Die nächst höhere Zweierpotenz von 5 ist 8. Wenn der Vektor tatsächlich so implementiert ist, dass er immer zweierpotenzen von Speicher reserviert, dann wären das für 30 Elemente dann 32 Byte. Und das ist durchaus möglich, dass die Vektoren das so machen.

Aber mal im Ernst, wen interessiert das schon, ob ein Programm jetzt 8 Byte oder 8 kByte reserviert. Das wird erst dann interessant, wenn man entweder für Mikrocontroller programmiert, oder wenn die benötigten Speichermengen deutlich höher sind. Das gleiche gilt für Laufzeit bei Verwaltungsoverhead. Das heißt aber nicht, dass man sich nicht trotzdem Gedanken machen sollte, welche Datenstruktur für das gegebene Problem am besten passt.
Im gegebenen Fall ist die Größe der Daten konstant und zur Compilezeit bekannt, also ist die logisch richtige Datenstruktur ein Array. Dass ein std::array einem C array vorzuziehen ist gebe ich zu (berechtigte Kritik an meinem vorherigen Post), aber ein Array ist es trotzdem. std::vector ist genauso geeignet, da die größe Konstant ist sind die Kosten für die Größenänderung irrelevant.

**blueshark27** · 20. 01. 2012, 08:24

>> Das mag bei manchen (schlechten) Compilern so sein, in der Regel sind Vektoren intern aber dynamische Arrays.
>> Die Größe des reservierten Speichers ist vom Standard ebensowenig vorgegeben.

Die stl ist Bestandtteil des C++-Standards, darum kann davon ausgegangen werden, dass bei (fast) allen Anwendern der stl-Vektor zum Einsatz kommt.

>> Netter Versuch, stimmt aber leider nicht.

stefbrot hatte das schon korrigiert. Ich meinte nicht den gesamten Speicher, der reserviert wird. In meinem Beispiel macht es keinen Unterschied, ob ein Vektor für fünf, sechs, sieben oder acht Elemente angelegt wird.

>> Wenn die Anzahl vorher bekannt...

Mit vorher meinte ich zum Programmstart. Hatte ich nicht klar genug ausgedrückt.

>> Auf kleinen Mikroprozessoren und Embedded Systems vielleicht...

Kommt auf die Datengroße an. Ich hatte diese Probleme auf einem "normalen" PC, der sogar extravagant ausgerüstet war (schneller Prozessor, viel Arbeistspeicher, etc.). Als ich mit großen Punktwolken arbeite bin ich genau auf dieses Problem gestoßen. Rechnerich hätte der Speicher ausgereicht, da aber der Vektor entsprechend mehr reserviert hat, ist das Programm stets abgestürzt.

>> Aber wenn es darum geht, Elemente in der Mitte einzufügen, ist der Vektor sogar immernoch performanter.

Zugegeben, unter diesem Aspekt habe ich den Vektor und Deque nicht verglichen. Mir ging es damals um Speicherperformance und seitdem bin ich bei Vektoren vorsichtig.
So habe ich auch wieder etwas dazugelernt :-)

**Jodocus_** · 20. 01. 2012, 17:41

>> Die stl ist Bestandtteil des C++-Standards, darum kann davon ausgegangen werden, dass bei (fast) allen Anwendern der stl-Vektor zum Einsatz kommt.

Aber die Art wie der Vektor implementiert ist, ist nicht vorgegeben. "Die" STL gibt es nicht. Du kannst keine allgemeine Aussage über die Reservespeichergröße eines C++-Vektors sagen. Im Standard steht nur, dass der Reserverspeicher größergleich der Vektorgröße ist. Z.B. ein 100-Elemente-Vektor nach dem Code von http://www.cplusplus.com/reference/stl/vector/capacity/ erzeugt mit VS 2010 bei mir einen "Overhead" von 41 Elementen, mit 'nem GCC sind es 28, also einiges weniger.

>> stefbrot hatte das schon korrigiert. Ich meinte nicht den gesamten Speicher, der reserviert wird. In meinem Beispiel macht es keinen Unterschied, ob ein Vektor für fünf, sechs, sieben oder acht Elemente angelegt wird.

Da hab ich dich falsch verstanden, sorry. Die Art, die ich vorgegeben habe ist aber auch eine gängige Methode in Vektorimplementierungen Speicher zu reservieren.

>> Kommt auf die Datengroße an. Ich hatte diese Probleme auf einem "normalen" PC, der sogar extravagant ausgerüstet war (schneller Prozessor, viel Arbeistspeicher, etc.). Als ich mit großen Punktwolken arbeite bin ich genau auf dieses Problem gestoßen.

In der Tat, die Datengröße ist relevant. Aber du musst wissen, dass das weniger an der tollen Arbeitsspeichergröße lag, sondern u.U. daran, dass es in deinem Programm-Heap zwar genug freie Speicherstellen gab, diese aber nicht an einem Block hingen, wie es ein Vektor jedoch verlangt.
Dein Anwendungsgebiet ist außerdem für den TE von eher exotischerer Art und hier bzw. in den allermeisten Anwendungsgebieten eher irrelevant. Neben Embedded Systems hat man es eben auch in der numerischen Programmierung für Wissenschaften mit gewissen Extrema zu tun, einerseits wegen der wenigen Hardware, andererseit wegen vieler großer Zahlen. Das wars dann aber auch schon.
In C++ nimmt man deshalb für sowas die valarrays, die Extra für die Numerik geschaffen wurden.

>> und seitdem bin ich bei Vektoren vorsichtig.

Vektor hat von allen Containern die schnellste Lese- und Schreibgeschwindigkeit und sollte immer auf Platz 1 der Verwendung stehen, außer man hat gute Gründe, einen anderen Container zu verwenden, etwa wenn der Vektor zu groß wird, man andere Indizes als Zahlen braucht oder man (besonders mittendrin) viel einfügen und löschen muss.