#include <iostream>

using namespace std;

int main()
{
    double y;

    y=(19/5+0.5)*10;
    cout <<y <<endl;

    float x;

    x=(19/5+0.5)*10;
    cout <<x <<endl;

    x=(19/5+0.5f)*10;
    cout <<x <<endl;

    return 0;
}

als ausgabe erhalte ich:

35
35
35
35

19/5 = 3,8
3,8 + 0,5= 4,3
4,3 * 10 = 43

Kann mir wer sagen wie das kommen kann?
Oder habe ich hier nen blöden Fehler drine?

19 / 5 = 3
3 + 0.5 = 3.5
3.5 * 10 = 35

et voilà

Edit:

Wenn du die Ganzzahldivision verhindern möchtest, kannst du es z. B. so schreiben:

double y=(19.0/5+0.5)*10;

ok danke für die schnelle Antwort

Man würde ja erwarten, dass, wenn man eine Variable als "float" definiert,
tatsächlich auch gleich die FPU angeworfen wird zum Zwischenspeichern, Rechen und natürlich auch Ausgeben.

Bei Haskell wird dieses Problem ein wenig anders angegangen. Wenn man die Zahlen in den ghci eingibt, ergibt sich folgendes:

Prelude> :set +t
Prelude> (19/5 + 0.5) * 10
43.0
it :: Fractional a => a

Was passiert eigentlich, wenn man bei c++ int a = 5.5; schreibt?

Die rechte Seite weiß in C++ nichts von der linken Seite und das ist auch gut so. Man stelle sich nur mal vor:

string foo = to_string(5 + 6)  // "56", weil Stringaddition?

Und das ist noch ein super-simpler Fall.

Man würde ja erwarten, dass, wenn man eine Variable als "float" definiert,
tatsächlich auch gleich die FPU angeworfen wird zum Zwischenspeichern, Rechen und natürlich auch Ausgeben.

also wir haben gelernt, dass das eben nicht so ist, bzw. dass die fpu nur dann verwendet wird, wenn auch eine gleitkommazahl an der rechenoperation teilnimmt und das ist ja bei 19/5 nicht der fall.

Man würde ja erwarten, dass, wenn man eine Variable als "float" definiert,
tatsächlich auch gleich die FPU angeworfen wird zum Zwischenspeichern, Rechen und natürlich auch Ausgeben.

Nein. Compiler kennen viele Tricks, und Integer-Operationen sind in der Regel weniger teuer als Gleitkommaberechnungen. Selbst, wenn diese Integer-Operationen auf den ersten Blick sehr komplex erscheinen.

Das wussten auch die Entwickler von Doom. Anstatt dass sie Gleitkommazahlen verwenden, haben sie mit Bitshifting eine Lösung gefunden, die nahe genug am Ergebnis war.

nachtfeuer schrieb:

Was passiert eigentlich, wenn man bei c++ int a = 5.5; schreibt?

Darauf hat dir SeppJ schon eine Antwort gegeben, aber ich habe da noch was in C nachgeprüft:

#include <stdio.h>

int main(void)
{
        printf("%f\n",5.5f);
        return 0;
}

Aus der Übergabe von 5.5f macht der Compiler:

movabs rax,0x4016000000000000

5.5f siehst du gar nicht mehr, nur noch 0x4016000000000000.

5.5f siehst du gar nicht mehr, nur noch 0x4016000000000000.

Du meinst, der Compiler versteht Literale und printf? Ich verstehe nicht, was das mit dem Thema zu tun hat.

Erklärung für andere Leser: 0x4016000000000000 ist 5.5 (also double).

edit: eben

Du meinst, der Compiler versteht Literale und printf? Ich verstehe nicht, was das mit dem Thema zu tun hat.

Es war eine Ergänzung zu der Erwartung, dass der Compiler bei Gleitkommaoperationen direkt spezielle FPU-Instruktionen generiert. Tut er in dem TE-Beispiel nicht, weil mit Integeroperanden gearbeitet wird. Aber selbst wenn mit Gleitkommaoperanden gearbeitet wird, müssen keine FPU-Instruktionen generiert werden, wenn der Compiler erkennt, dass das Ergebnis auch mit simpleren Operationen berechnet werden kann.

HansKlaus schrieb:

gleitkommazahlenformat mit exponent und mantisse?

Nach IEEE754.

In den 70er Jahren waren Fließkommaprozessoren noch nicht so verbreitet. Beim Intel konnte man einen als Zusatz kaufen oder eine (langsame) Softwaresimulation nutzen.

Intel (und Kompatible) haben mittlerweile sehr viele Hardware-Datentypen parat. Ein wenig Automagie wäre nicht so verkehrt? Wo anfangen?

Man könnte noch fragen: Was hat der Compiler (oder die Programmiersprache)(wenn schon Int) mit dem Rest von 19/5 gemacht?

(Hardwaresimulation in Haskell:
(ghci)

Prelude> let divmod a b = (div a b, mod a b)
Prelude> divmod 19 5
(3,4)

ich würde eher sagen, dass da ein cast durchgeführt wird.

Da wird gar nichts durchgeführt.