Aufgabe gut gelöst?

NilsV

So wie ich das geschrieben habe, benötigte ich die Variable ja schon in der nächsten Zeile als Bedingung für die While-Schleife.

Ich würde da auch lieber Prüfen ob tipp richtig ist, dafür müsste ich meine ausgedachte Zahl aber am Anfang eingeben (Würde das Raten irgendwie witzlos machen).

[EDIT]:
Sorry, hab mich voll vertan. Du meintest tipp, ich war irgendwie bei answer. Hab mich da vertan, nun ist alles klar.

volkard

NilsV schrieb:

In dem Buch werden Variablen (bisher) in den Code-Schnipseln eigentlich immer Initialisiert, selbst wenn sie z.B. 2 Zeilen später durch eine Eingabe einen neuen Wert zugewiesen bekommen.

Die Eingabe in C++ ist leider sehr uncool. Bei der Eingabe gibt es keinen schönen Weg.

NilsV schrieb:

Ich denke solange ich das Buch durcharbeite halte ich mich besser an das was dort gezeigt wird.

Das denke ich nicht. Bei Stilfragen wie den Klammern klar. Aber Variablen lokaler machen ist echt klasse und answer=" " ist echt unklasse. Warum nicht answer="sigma phi gamma"?

*Rewind*

Für den Vergleich von Strings gibt es dazu bestimmte Memberfunktionen (compare()).
Und wo wird die Anzahl von Versuchen gezählt? Für die Aufgabe ist diese Größe wichtig, also solltest du sie auch überprüfen.

Meine persönliche Meinung: die letzte Überprüfung in der while-Schleife ist überflüssig, da dies durch die Schleifenbedingung gewährleistet wird.
Ich würde einfach am Ende die Zahl ausgeben:

[...]
    while(answer != "gleich") {
        if(is_smaler_or - is_bigger > 2) {
            tipp = ((is_smaler_or - is_bigger) / 2) + is_bigger;
            answer = ask(tipp);
            if(answer == "größer") {
                is_bigger = tipp;
            }
            else if(answer == "kleiner") {
                is_smaler_or = tipp;
            }
        }
        else {
            cout << "Die gesuchte Zahl ist " << is_smaler_or - 1 << '\n';
            answer = "gleich";
        }
    }
    cout << "Die gesuchte Zahl ist " << tipp << '\n';
[...]

Noch ein kleiner Tipp: ich weiß nicht, ob du das schon hattest, aber mit dem arithmetischen IF (also ? : ) man kann einfache Überprüfungen und darauf folgende einzeilige Prozeduren sehr schön miteinander "verschmelzen". Hier ist es aber von geringer Bedeutung.

volkard

NilsV schrieb:

So wie ich das geschrieben habe, ...

Tja. Probier's mal mit dem häßlichen for(;;). Ob das damit echt hübscher wird, muß man mal schauen. Kann sein, daß die unlokale Variable und while das kleinere Übel ist. Aber man sieht es erst genau, wenn man es ausprobiert und Folgeoptimierungen (falls möglich) ausführt.

volkard

[Rewind] schrieb:

Für den Vergleich von Strings gibt es dazu bestimmte Memberfunktionen (compare()).

Aber == ist angemessener.

[Rewind] schrieb:

Und wo wird die Anzahl von Versuchen gezählt? Für die Aufgabe ist diese Größe wichtig, also solltest du sie auch überprüfen.

Nö. Zählen ist nicht nötig.

[Rewind] schrieb:

Noch ein kleiner Tipp: ich weiß nicht, ob du das schon hattest, aber mit dem arithmetischen IF (also ? : ) man kann einfache Überprüfungen und darauf folgende einzeilige Prozeduren sehr schön miteinander "verschmelzen".

Du meinst "sehr häßlich". Meiner Meinung nach könnhte man den ?: auch abschaffen. Das würde viel Unfug verhindern. Ich verwende ?: seltener als goto oder mehrfache Erblichkeit. So schlimm ist das.

volkard

Außerdem schreibt man tip mit nur einem p und smaller mit zwei l.
Vielleicht ist der der unglückliche Name is_smaler_or zurückzuführen darauf, daß Dein Englisch-Wortschatz nicht so mächtig fett ist, wie dein deutscher? Dann wäre es doch schlau, die Bezeichner auf deutsch zu schreiben, um treffendere Namen zu finden und das Augenmerk ohne externe Behinderung auf extrem hübsches Programmieren legen zu können.

NilsV

answer = "gleich";//Hä? Och nöö. break wäre erträglich, return wäre viel besser

Weder continue / break noch das man mehrere return Anweisungen haben kann, kam im Buch bisher dran. Ich kenne die Sachen zwar (Hab mir vorher schon ein paar Grundlagen angeeignet), denke aber das es im Sinne der Aufgaben ist, mit dem zu arbeiten was das Buch einem bisher erklärt hat.

volkard

NilsV schrieb:

Sorry, hab mich voll vertan. Du meintest tipp, ich war irgendwie bei answer. Hab mich da vertan, nun ist alles klar.

Nein.
tipp meinte ich natürlich. Die schreit ja danach, lokaler zu werden.

Aber answer meinte ich auch!
Aber auf Kosten der Schleifenbedingung und mit ersatzuweisem if() break; vielleicht.
Es würde die Variable lokaler machen (nicht so wichtig) und die Untersuchung stärker zusammenhalten (schon wichtiger), statt sie so ausgefranst zu haben, ein teil im while, ein Teil im, Schleifenkörper und dort sogar mit verschachteltem if.
Gehts mit geeignetem break bzw continue nicht irgendwie, das verschachtelte if loszuwerden?

volkard

NilsV schrieb:

Weder continue / break noch das man mehrere return Anweisungen haben kann, kam im Buch bisher dran. Ich kenne die Sachen zwar (Hab mir vorher schon ein paar Grundlagen angeeignet), denke aber das es im Sinne der Aufgaben ist, mit dem zu arbeiten was das Buch einem bisher erklärt hat.

Dann lies das Buch im Sondereiltempo jetzt durch bis hinten hin. Und dann lies es zum zweiten mal normal und bearbeite die Aufgaben, diemal aber mit Überblick.
Es kann nicht Sinn der Sache sein, daß Du Dir jetzt einen Kindergartenstil angewöhnst.

break und continue gehören untrennbar zu Schleifen. mehrere returns gehören untrennbar zu Funktionen. Das halte ich nicht für was austauschbares, wie ob man std::find_if benutzt oder selber eine Suchschleife nimmt, weil man std::find_if nocht kennt oder nicht mag.

otze

NilsV schrieb:

answer = "gleich";//Hä? Och nöö. break wäre erträglich, return wäre viel besser
Weder continue / break noch das man mehrere return Anweisungen haben kann, kam im Buch bisher dran. Ich kenne die Sachen zwar (Hab mir vorher schon ein paar Grundlagen angeeignet), denke aber das es im Sinne der Aufgaben ist, mit dem zu arbeiten was das Buch einem bisher erklärt hat.

Der Sinn solcher Aufgaben ist es, dass man sie immer versucht so gut wie irgendmöglich zu lösen. Es steht zwar nie in den Büchern drin, aber die Autorne wollen auch zum einen, dass man auch vor-ließt, zum anderen, dass man die Aufgaben wiederholt mit dem neuen Wissen löst.
Das Problem an diesen Aufgaben ist, dass sie Plakativ irgendwelche Sprachfeatures zeigen sollen. Wenn im Buch switch dran kommt, dann wird irgendeine Aufgabe genommen in der sich Switch anbietet. In der Praxis ersetzt du aber Switch eigentlich immer durch andere, bessere Konstruktionen. Die Aufgabenlösungen mit den bekannten Features stellen also kein Optimum da.

314159265358979

@volkard: Was hast du denn gegen ?: ?
Ich stimme dir zu, dass er zu oft verwendet wird, aber gelegentlich ist er doch ganz praktisch.