Abfrage.. bin zu blöd...

Martini123

void spiel(){
cout << "Willst du die Spielregeln lesen? [J/N]" << endl;
cin >> regeln;
if(regeln == 'J'){
spielregeln();
}
else if(regeln == 'N'){
cout << "h" << endl;
}
};

//so müsste es gehen

Simon2

El Kassem schrieb:

Man .. es ist echt zum weinen ..
Warum funktioniert das nicht ..
void spiel(){
     cout << "Willst du die Spielregeln lesen? [J/N]" << endl;
     cin >> regeln;
     if(regeln = "J"){
     spielregeln();
     }
     if(regeln = "N"){
     cout << "h" << endl;
     }
     };
Ich werd verrückt .. kp warum nicht .. hab alles probiert.. mit zwei == .. us.w.
ne idee ?

Da fehlt Entscheidendes: Welchen Typ hat die Varaible "regeln" ? Falls das char* ist, kann das nicht funktionieren (nicht mal mit dem richtigen "==")... dann nimm doch einfach std::string aus dem #include <string>.
Und mit dem "=" weist Du zu, d.h. nach dem Statement regeln = "J" (egal, ob es in einem "if" steht oder nicht) HAT regeln den Wert "J" ... egal, was es vorher hatte.
Wenn Du danach nochmal regeln = "N" machst, HAT danach regeln den Wert "N".... das bedeutet: Du schaffst Tatsachen, statt sie abzufragen (das täte man mit "==").

Ach ja: besser keine globalen Variablen verwenden (hier aller Voraussicht nach "regeln").

Gruß,

Simon2.

El Kassem schrieb:

Man .. es ist echt zum weinen ..
Warum funktioniert das nicht ..
void spiel(){
     cout << "Willst du die Spielregeln lesen? [J/N]" << endl;
     cin >> regeln;
     if(regeln = "J"){
     spielregeln();
     }
     if(regeln = "N"){
     cout << "h" << endl;
     }
     };
Ich werd verrückt .. kp warum nicht .. hab alles probiert.. mit zwei == .. us.w.
ne idee ?

In der guten alten BASIC-Zeit war es noch möglich, Zeichenketten mittels einfachem = miteinander zu vergleichen. In C++ muss man für jeden Vergleich == schreiben. Damit man einen Vergleich von einer Zuweisung auch optisch unterscheiden kann.
Soferne die Variable 'regeln' ein 'Zeiger auf char' sein sollte, und außerdem der Speicher, auf den 'regeln' zeigt, auch wirklich Deinem Programm gehört (beispielsweise weil Du den Speicher mit malloc oder new angefordert hast), ist gegen den Versuch, mittels

cin >> regeln;

eine Eingabe vom Benutzer entgegen zu nehmen, nicht viel einzuwenden.
Wenn Du Dir den Speicher anforderst, sollte das Array auch groß genug sein, um die Benutzereingabe einlesen zu können.

Es wäre für Deine Zwecke eigentlich ausreichend, nur ein vereinzeltes Zeichen einzulesen, und nicht eine komplette Zeichenkette. Das hätte den Vorteil, dass Du in den if-Anweisungen auch weiterhin mittels == die Eingabe des Users mit dem konkreten Buchstaben vergleichen könntest.
Der Vergleich von Zeichenketten gestaltet sich etwas (minimal) unbequemer (Beispielsweise mit der Bibliotheksfunktion strcmp()).

#include <stdio.h>
void spiel(){

     char regeln; 
       // Zuerst stellen wir eine Variable fuer die Eingabe bereit
       // im Unterschied zu einigen anderen Programmiersprachen
       // möchte ein C++ Compiler immer zuerst wissen, was in einer
       // Variable gespeichert werden soll, bevor man sie verwenden kann

     printf("Willst Du die Spielregeln lesen? [J/N] >> "); 

     regeln = fgetc(stdin);
      // Hier lesen wir den Buchstaben ein. stdin ist ein
      // Dateizeiger, der mit dem Tastaturpuffer verbunden ist.
      // Von dort holt die Funktion fgetc() den Buchstaben ab, den der
      // Benutzer eingibt. Schliesslich fangen wir den Rückgabewert der
      // Funktion in der Variablen c auf _ Ein weiteres Beispiel für
      // den Zuweisungsoperator '=', der nur bei Zuweisungen verwendet wird.

     while(fgetc(stdin)!='\n')
          ;

     // Hier gibt es das Problem, dass die meisten Tastaturfunktionen
     // den Eingabepuffer NICHT leeren, bzw. je nach Lust und Laune es
     // auch manchmal schon tun. Das gilt nicht nur für fgetc(),
     // sondern ebenso für cin. Die unangenehmen Folgen dieser
     // 'Verschlafenheit der Eingabefunktionen' treten in der Regel
     // frühestens beim nächsten Gebrauch einer Eingabefunktion zutage.
     // Was auch immer die unangenehmen Folgen wären: mit der obigen
     // while-Schleife treten sie nicht (leicht) ein.
     // Anstatt jedesmal die Schleife nach jeder Eingabe schreiben zu müssen,
     // kann man auch ein #define verwenden.

     if(regeln == 'J'){  // Wie erwaehnt: Es sollten zwei == sein, um zu
                       // vergleichen. Bei einem vereinzelten Buchstaben
                       // als Vergleichsoperand verwendet man vereinzelte
                       // Hochkommata '

          spielregeln();    //  Was auch immer diese Funktion macht ...
     }

     else if(regeln == 'N'){  // hier eher 'else if' als nur 'if' (zumindest
                              // von der Logik her)
        printf("h");
     }
     };

Es scheint aber so zu sein, dass Du entweder aus einer syntaktisch total unterschiedlichen Programmiersprache kommst (etwa BASIC), oder es eben einfach noch etwas an Übung fehlt.
Auch wenn man mittlerweile kaum noch gute C++ Bücher antrifft, probier's z.B. mit 'C++ von A bis Z Das umfassende Handbuch'. Zwar versucht auch hier der Autor, den Leser zu einem 'genormten' C++-Programmierer zu 'erziehen', der sich gefälligst an den Standard zu halten hat, aber immerhin wird in einigen Randbemerkungen noch darauf hingewiesen, dass C-Funktionen in C++ einsetzbar sind. Auch wenn es nicht empfohlen wird. Warum? Niemand weiß es genau. Ist eben so eine Meinung. (Hinweis: Es gibt keinen objektiven Grund, eine Funktion, die eine Aufgabe zufriedenstellend löst, NICHT auf zu rufen.)

mfg
(und nicht entmutigen lassen!)

Badestrand

Gut erklärt!

CodeFinder

@Narrensicher: Das ist aber C, kein C++ .

queer_boy

Narrensicher schrieb:

Auch wenn man mittlerweile kaum noch gute C++ Bücher antrifft, probier's z.B. mit 'C++ von A bis Z Das umfassende Handbuch'. Zwar versucht auch hier der Autor, den Leser zu einem 'genormten' C++-Programmierer zu 'erziehen', der sich gefälligst an den Standard zu halten hat, aber immerhin wird in einigen Randbemerkungen noch darauf hingewiesen, dass C-Funktionen in C++ einsetzbar sind. Auch wenn es nicht empfohlen wird. Warum? Niemand weiß es genau. Ist eben so eine Meinung. (Hinweis: Es gibt keinen objektiven Grund, eine Funktion, die eine Aufgabe zufriedenstellend löst, NICHT auf zu rufen.)

typensicherheit z.b. bei den funktionen. plus std::string *ist* einfacher und intuitiver als ein ein NTBS und die zugehörigen strxxx funktionen. wenn man mit den standardcontainern arbeitet und sich dabei für den c++-way entschieden hat, ist es äußerst unklug, den code mit anderen (C-)funktionen zu mischen. (z.b. sollte man dann bei cout/cin sync_with_stdio angeben)

und ein "genormter" c++ programmierer, wird wohl kaunm #include <stdio.h> in seinen programmen verwenden. das heißt #include <cstdio> und die funktionen daraus liegen im namespace std. damit ist das, was du geschrieben hast, tatsächlich *nicht* c++.

LordJaxom

Narrensicher schrieb:

(Hinweis: Es gibt keinen objektiven Grund, eine Funktion, die eine Aufgabe zufriedenstellend löst, NICHT auf zu rufen.)

Wenn eine Funktion in C++ sicherer implementiert werden konnte als die äquivalente C-Funktion, weil die Sprache die Mittel dazu bietet, gibt es keinen objektiven Grund, sie NICHT zu benutzen.

Badestrand

queer_boy schrieb:

und ein "genormter" c++ programmierer, wird wohl kaunm #include <stdio.h> in seinen programmen verwenden. das heißt #include <cstdio> und die funktionen daraus liegen im namespace std.

Warum hängt sich daran eigentlich immer jeder auf? Das ist doch sowas von nebensächlich, dass es zum Schreien ist. Soweit ich weiß hat es keine Auswirkungen auf irgendwas, genauso ob man nun "int main()" oder "void main()" oder "int main( int argc, char *argv[], char *envp[] )" schreibt. Sobald man genug kann, um ernsthaft zu programmieren, spielt das absolut keine Rolle mehr und ansonsten verwirren die Diskussion die armen Anfänger nur

queer_boy schrieb:

damit ist das, was du geschrieben hast, tatsächlich *nicht* c++.

Klar... C++ muss doch nicht zwingend aus den in-/outstreams bestehen. Du kannst dir ein xk-Zeilen-Projekt basteln, was angeblich nicht C++ wäre. Ist es aber.

Hallo

Na ganz so egal ist das ja nun nicht. Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht (portieren, anderer compiler) Das muss doch nicht sein. Und ebenson ist c eben nicht c++

chrische

chrische5 schrieb:

Hallo

Na ganz so egal ist das ja nun nicht. Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht (portieren, anderer compiler) Das muss doch nicht sein. Und ebenson ist c eben nicht c++

chrische

Und in drei Jahren beschließt irgend ein erlauchtes Gremium einen neuen Standard, der wieder völlig andere Dinge 'vorsieht'. Dass Programmiersprachen sich im Laufe der Zeit immer wieder verändert haben, ist ganz normal. Solange man ein paar wenige Grundkonzepte kapiert, ist es auch unerheblich, was momentan gerade 'der Standard' ist. Weil in wenigen Jahren kann es schon wieder ganz anders aussehen.
Jeder sollte bis zu einem gewissen Grad 'seinen eigenen Standard' bzw. 'Stil' entwickeln. Denn wirklich 100% standardgetreu programmiert niemand.

Simon2

Narrensicher schrieb:

...Denn wirklich 100% standardgetreu programmiert niemand.

Na, das ist wohl mehr Klischee ("nobody is perfect", "So jung kommen wir nich wieder zusammen", ....) als Realität.
Und außerdem IMO kein Argument, nicht wenigstens zu versuchen standardkonform zu programmieren.

Ich würde mal andersherum sagen: Wer ein guter (oder besserer) Programmierer werden will, sollte den Standard kennen - und sei es nur, um zu wissen, wo er davon abweicht und welche Risiken er damit eingeht.

Die Tatsache, dass es verschiedene Standards gibt (derzeit C++98, später vllt. mal C++0x), bedeutet auch nicht, dass man sie nicht kennen muss, sondern das Gegenteil.

Gruß,

Simon2.

asc

Narrensicher schrieb:

chrische5 schrieb:

...Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht...

Und in drei Jahren beschließt irgend ein erlauchtes Gremium einen neuen Standard, der wieder völlig andere Dinge 'vorsieht'. ... Solange man ein paar wenige Grundkonzepte kapiert, ist es auch unerheblich, was momentan gerade 'der Standard' ist. Weil in wenigen Jahren kann es schon wieder ganz anders aussehen. ...

Dem schließe ich mich absolut nicht an. Das mag zwar für ein Hobbyprogrammierer der niemals in einen Team arbeiten wird nicht so relevant sein, aber ein Standard hilft auch beim verstehen fremden Codes. Man sollte sich IMHO immer so weit an einen Standard halten, wie der Compiler es zulässt.

Und wer sich wirklich ernsthaft mit einer Sprache auseinander setzen will (ob nun Privat oder Beruflich) sollte sich zumindest in Grundzügen ab und zu umschauen ob ein neuer Standard (ich sage hier z.b. C++0x) kommt, und was sich im groben ändern könnte.

cu André

Badestrand

Klar sollte man sich an den Standard halten, aber ob man die <stdio> oder die <stdio.h> einbindet, ist sowas von schei*egal

Abgesehen davon schließt C++ nunmal C mit ein, ob du's willst oder nicht. "printf" ist eine genauso zulässige C++-Anweisung wie "cout <<". C++ ist eine Programmiersprache und keine Bibliothek. Was ihr meint, ist, dass manche C++-Programme auch C-Programme sind, das macht sie aber noch lange nicht nicht-C++.

Und eine Nebenfrage: Worin entscheidet sich eigentlich sogenannter "standard-konformer" C++-Code von "nicht-standard"-Code?
Zwei Beispiele hätten wir schonmal: <stdio> vs <stdio.h> und die main-Funktion, eventuell noch die C++-Streams im Gegensatz zu den "printf" / "str..."-Funktionen.
Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. Wichtig ist allein, dass man beides kennt und halbwegs mit umgehen kann, was man davon nun verwendet bleibt wohl jedem selber überlassen...

David_pb

Badestrand schrieb:

Klar sollte man sich an den Standard halten, aber ob man die <stdio> oder die <stdio.h> einbindet, ist sowas von schei*egal

Das ist eben nicht egal. Der Header stdio.h ist eben kein Standard und muss deshalb nicht angeboten werden. Wenn du ein Programm schreibst und auf einem anderen Compiler compilierst das diesen Header nicht hat dann hast du erstmal schön viel Arbeit alles anzupassen...

Es geht nicht um solchen Kleinkram. Printf etcpp sind auch im C++ Standard enthalten, da diese Funktionen aber alte Fragmente aus C sind und nicht von den C++ Vorteilen (Typsicherheit, ...) profitieren sollte man diese möglichst meiden.

Und das mit main ist sowiso so ne Sache. Laut C++ Standard sind gültig:

int main(); // int main( void );
int main( int argc, char** argv );

Sonst nichts. Laut C Standard sind auch andere Rückgabewerte erlaubt, z.B.:

void main();

Und schon sind wir wieder beim Thema. Du schreibst ein C++ Programm mit void main() {} Funktion und gibst es einem Kollegen der einen Compiler verwendet welcher keine unkonformen main Funktionen zulässt. Zack, schon muss er wieder rumeditieren.

Simon2

Badestrand schrieb:

...
Und eine Nebenfrage: Worin entscheidet sich eigentlich sogenannter "standard-konformer" C++-Code von "nicht-standard"-Code?...

Ganz einfach darin, dass sich Dein Code plötzlich auf einem anderen Compiler/System nicht mehr compilieren lässt.

Badestrand schrieb:

...Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. ...

Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.

Gruß,

Simon2.

asc

Badestrand schrieb:

...Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. ...

Irrelevant?

Dann nehmen wir doch mal das ganz einfache Beispiel "new".

Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).

cu André

Badestrand

Gut, da scheinen unsere Meinungen ja auseinanderzugehen...

Simon2 schrieb:

Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.

Nein, wenn es nur um "main" und "<stdio>/.h" geht, ist es irrelevant. Da brauchst du nämlich für ein noch so großes Projekt 2 Minuten und nicht 5 Monate.

asc schrieb:

Dann nehmen wir doch mal das ganz einfache Beispiel "new".
Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).

Das ist dann was anderes, das meinte ich nicht. Sowas ist natürlich relevant und jeder C++-Programmierer sollte wissen, dass "new" Exceptions schmeißt, statt NULL zurückzugeben. Das gehört schließlich schon zum Sprachkonzept dazu und hat inhaltliche Auswirkungen, eben anders als die vorher erwähnten Sachen

David_pb

Badestrand schrieb:

Gut, da scheinen unsere Meinungen ja auseinanderzugehen...

Simon2 schrieb:

Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.

Nein, wenn es nur um "main" und "<stdio>/.h" geht, ist es irrelevant. Da brauchst du nämlich für ein noch so großes Projekt 2 Minuten und nicht 5 Monate.

Je nach größe des Projekts und Unterschieden kann eine Portierung durchaus mehrere Monate dauern. Und wenn du nur zwei Minuten dazu brauchst, es sind zwei Minuten zu viel!

Badestrand schrieb:

asc schrieb:

Dann nehmen wir doch mal das ganz einfache Beispiel "new".
Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).

Das ist dann was anderes, das meinte ich nicht. Sowas ist natürlich relevant und jeder C++-Programmierer sollte wissen, dass "new" Exceptions schmeißt, statt NULL zurückzugeben. Das gehört schließlich schon zum Sprachkonzept dazu und hat inhaltliche Auswirkungen, eben anders als die vorher erwähnten Sachen

Ist auch nichts anderes als iostream.h, stdio.h o.ä. zu verwenden. Nur mit ein wenig drastischeren Folgen.

Badestrand

David_pb schrieb:

Je nach größe des Projekts und Unterschieden kann eine Portierung durchaus mehrere Monate dauern. Und wenn du nur zwei Minuten dazu brauchst, es sind zwei Minuten zu viel!

Das ist gröbster Unfug. Die main-Funktion von "void main()" in "int main()" umzubauen, dauert etwa 20 Sekunden, wenn du noch das "return 0;" dazunimmst.
Wenn die betreffenden Header mit ".h" statt ohne eingebunden sind, lässt du sie in allen Dateien automatisch ersetzen. Und wenn ich nur 2 Minuten zum portieren brauche (was man ja auch nicht gerade häufig macht), dann bin ich einfach nur glücklich!

David_pb schrieb:

Ist auch nichts anderes als iostream.h, stdio.h o.ä. zu verwenden. Nur mit ein wenig drastischeren Folgen.

Ähm... Ist schon was anderes... Einfach mal drüber nachdenken...

Ich sage nicht, dass man möglichst nicht nach dem C++-Standard programmieren soll. Ich sage nur, dass es Schwachsinn ist, jeden Anfänger (oder auch Fortgeschrittenen) wegen "void main" anzuschnauzen

Braunstein

Badestrand schrieb:

...
Wenn die betreffenden Header mit ".h" statt ohne eingebunden sind, lässt du sie in allen Dateien automatisch ersetzen. Und wenn ich nur 2 Minuten zum portieren brauche ...

Die Tatsache, das du dann den namespace std mit beachten mußt stört dich da nicht?