3. Inkrementieren - verwirrt

Inkrementieren - verwirrt

  • L

    Also es geht um Folgendes:

    Um Präprozessor.

    Und wenn man da einen Ausdruck hat wie:

    #define QUADRAT(a) ((a)*(a))

...

int Zahl = 5;
Wert = QUADRAT(++Zahl);

    So hat die Variable Wert zum Schluss den Inhalt 49, weil berechnet wird:

    ((++Zahl)*(++Zahl))

    [Das habe ich aus dem Buch "Einstieg in C++" von A. Willemer.]

    Wieso kommt da 49 heraus?

    0
  • ?

    Es ist undefiniertes Verhalten!
    Das wurde doch jetzt schon mehrfach gesagt.

    Lies dazu auch den Wiki-Artikel der hier verlingt wurde.

    0
  • Mod

    LinuxC_newbie schrieb:

    [Das habe ich aus dem Buch "Einstieg in C++" von A. Willemer.]

    Ein guter Grund, das Buch sofort wegzuwerfen, wenn das da wirklich so steht.

    0
  • V

    ghci schrieb:

    camper schrieb:

    Wieviele verschiedene Ergebnisse für j sind möglich? 😉

    ghci> length . nub . map ([a,b,c,d,e]->a*b*(c+1)*(d+1)+e) . permutations . take 5 $ [4..]
30

    Jup, sehe ich auch so.

    0
  • M

    LinuxC_newbie schrieb:

    Das habe ich aus dem Buch "Einstieg in C++" von A. Willemer.

    Gut zu wissen. Das Buch ist demnach nicht zu empfehlen.

    LinuxC_newbie schrieb:

    Wieso kommt da 49 heraus?

    Dabei muss nicht 49 herauskommen. Das Ergebnis ist undefiniert. Es kann also auch etwas anderes herauskommen. Die Frage nach dem "wieso" ist sinnlos.

    0
  • C
    Mod

    0
  • ?

    SeppJ schrieb:

    Ein guter Grund, das Buch sofort wegzuwerfen, wenn das da wirklich so steht.

    Nix da!

    @TE: Bewahre das Buch bis zum nächsten Winter auf, werfe es anschließend in den Kamin und wärm' Dir dabei die Füße.
    Wir wollen ja schließlich nicht verschwenderisch werden.

    0
  • C
    Mod

    volkard schrieb:

    ghci schrieb:

    camper schrieb:

    Wieviele verschiedene Ergebnisse für j sind möglich? 😉

    ghci> length . nub . map ([a,b,c,d,e]->a*b*(c+1)*(d+1)+e) . permutations . take 5 $ [4..]
30

    Jup, sehe ich auch so.

    ich nicht. Es gibt keinen Grund anzunehmen, dass der Konvertierungsoperator sofort nach dem Inkrementieren aufgerufen werden muss.

    0
  • L

    Dann nochmal eine andere Frage, wenn es okay ist:

    #includ<iostream>

#define X(C,D) ((C)>(D)?(C):(D))
#define Y(C) ((C)>0?(C):-(C))

#define A(B) B+B
#define C(D) D*D

using namespace std;

int main() {
   cout << X(1,100)<< endl;
   cout << Y(-100) << endl;
   cout << C(A(6)) << endl;
   cout << A(C(6)) << endl;
}

    (i) Welche Funktionalität beschreiben die Präprozessoranweisungen in den Zeilen 3 und 4?

    (ii) Welchen Quelltext sieht der Compiler in den Zeilen 14 und 15?

    Zu (i):
    Zeile 3: Maximumsfunktion
    Zeile 4: Betragsfunktion

    Zu (ii):
    Zeile 14: A(6)*A(6)=6+6*6+6
    Zeile 15: C(6)+C(6)=6*6+6*6

    Stimmt das?

    0
  • Mod

    Sieht richtig aus und lehrt dich hoffentlich, wieso man Makros eben nicht für solche Zwecke einsetzen sollte. Letzteres hast du darauf gelernt, oder?

    0
  • L

    Ja, das habe ich verstanden.

    Nur nicht, wieso für Zeile 14 und für Zeile 15 beim Ausführen

    48 und 72 ausgegeben wird.

    Denn ich dachte da müsste 78 und 252 stehen.

    0
  • M

    Der Compiler kennt Punkt-vor-Strich.

    0
  • Mod

    LinuxC_newbie schrieb:

    Ja, das habe ich verstanden.

    Nur nicht, wieso für Zeile 14 und für Zeile 15 beim Ausführen

    48 und 72 ausgegeben wird.

    Denn ich dachte da müsste 78 und 252 stehen.

    Dann hast du es eben gerade nicht verstanden. Nicht bloß blind nachplappern*, dass im Buch (hoffentlich) steht, dass Makros böse sind. Das Beispiel ist gerade dazu da, damit du auch verstehst, warum.

    *: Ja, das ist verführerisch, da man damit so tun kann, als ob man genau so viel verstanden hätte, wie die klugen Leute. Aber hat man in Wirklichkeit gar nicht.

    0
  • ?
     

    someone@somewhere:~$ echo "#include<iostream>

#define X(C,D) ((C)>(D)?(C):(D))
#define Y(C) ((C)>0?(C):-(C))

#define A(B) B+B
#define C(D) D*D

using namespace std;

int main() {
   cout << X(1,100)<< endl;
   cout << Y(-100) << endl;
   cout << C(A(6)) << endl;
   cout << A(C(6)) << endl;
}
" | g++ -E -x c++ - | sed -n -e '/main[[:space:]]*(/,/^}/p'
int main() {
   cout << ((1)>(100)?(1):(100))<< endl;
   cout << ((-100)>0?(-100):-(-100)) << endl;
   cout << 6 +6*6 +6 << endl;
   cout << 6*6 +6*6 << endl;
}
someone@somewhere:~$

    * scnr *

    0
  • L

    Ein freundlicher Umgangston sieht aber auch anders aus!
    Ich finde, dass ich mich hier nicht immer so blöde von der Seite anmachen lassen muss! Ich frage normal, und möchte auch normale Antworten haben, die nicht so von oben herab sind.

    Ich wiederhole nochmal, dass ich KEIN Informatiker bin und das auch nicht studiere. Vielmehr handelt es sich nur um einen kleinen einsemestrigen C++-Einschub im Rahmen meines Studiums.

    --------------------

    Es ist mir sehr wohl klar, was "das Böse" an Makros ist.

    Man würde erwarten, dass

    C(A(6))=144 ist, da A(6)=12. Es kommt aber C(A(6))=48 heraus.

    Ebenso würde man vermuten, dass A(C(6))=72. Und es kommt auch hier tatsächlich 72 heraus.

    0
  • M

    LinuxC_newbie schrieb:

    Man würde erwarten, dass

    C(A(6))=144 ist, da A(6)=12.

    A(6) ist nicht 12. A(6) ist 6+6.

    Der Präprozessor macht nur stumpfe Textersetzungen, er rechnet nicht.

    0
  • L

    Das habe ich doch geschrieben!

    Man würde intuitiv erwarten, dass da 144 rauskommt, kommts aber nicht, weil da nicht 12 sondern 6+6 steht.

    0
  • Mod

    Und jetzt die nächste Stufe der Bosheit:

    int i=6;
cout << C(i++);

    Was kommt raus und warum? (Bitte den Threadersteller antworten lassen!)

    P.S.:
    http://www.tty1.net/smart-questions_de.html
    http://www.tty1.net/smart-questions_de.html#keepcool
    http://www.tty1.net/smart-questions_de.html#not_losing

    0
  • L

    36

    0
  • Mod

    LinuxC_newbie schrieb:

    36

    Och, nö 😞
    So ein langer Thread und gar nichts daraus mitgenommen?

    0
Anmelden zum Antworten