Durch int Teilen

Hallo wie kann man zwei int zahlen teilen das eine Kommazahl raus kommt

Klar man könnte jetzt einfach float a,b nehmen aber das war nicht die Aufgabestellung.

Ich meine das wäre irgendwie so gewese aber jetzt krieg ich es nicht mehr hin....

#include <iostream>
using namespace std;

int main()
{
int a,b;
float erg;
cin>>a;
cin>>b;

erg = 1*a/b;

cout<<erg;
system("PAUSE");

}

zwutz

erg = 1.0 * a/b;

sothis_

erg = (float)a/(float)b;

Fellhuhn

Wenn ich 1 und dann 0 eingebe stürzt dein Programm ab. Wenn du sowas irgendwo abgeben willst, solltest du auf sowas achten.

Im Grunde reicht es wenn ein Operand ein float/double ist, zur Übersicht würde ich aber alle casten.

Nexus

sothis_ schrieb:

erg = (float)a/(float)b;

Bitte nicht in C++. Dafür gibts static_cast :

erg = static_cast<float>(a)/static_cast<float>(b);

Wobei ein Cast eigentlich reichen würde, aber man macht lieber gleich zwei, damit man besser sieht, was getan wird.

dooooomi

Nexus schrieb:

sothis_ schrieb:
erg = (float)a/(float)b;
Bitte nicht in C++.

Doch, bitte

Welchen Grund gibt es, für so etwas static_cast zu verwenden? Es sieht nicht hübscher aus (ganz im Gegenteil), es ist nicht lesbarer (ganz im Gegenteil), und es steckt auch keine zusätzliche Information drin. Oder übersehe ich da etwas?

Nexus

dooooomi schrieb:

Welchen Grund gibt es, für so etwas static_cast zu verwenden? Es sieht nicht hübscher aus (ganz im Gegenteil)

Hübsch oder nicht ist wohl Geschmackssache.

dooooomi schrieb:

es ist nicht lesbarer (ganz im Gegenteil)

Man kann sich darüber streiten, aber wenn man ein blau hervorgehobenes Schlüsselwort sieht, erkennt man meiner Ansicht nach schneller, worum es sich handelt, als einfach bei zwei schwarzen Klammern, zumal Klammern ja sehr viele Bedeutungen haben können.

Bei dem Minimalbeispiel mag man ja noch schnell den Cast sehen, aber stell dir mal einen grösseren Ausdruck vor, in dem noch Funktions-, Konstruktor-, operator() -Klammern plus noch zusätzliche für die Manipulation von Operatorprioritäten vorkommen.

dooooomi schrieb:

und es steckt auch keine zusätzliche Information drin. Oder übersehe ich da etwas?

Ja, du übersiehst, dass sehr wohl zusätzliche Information drinsteckt. Mit static_cast wird dem Compiler mitgeteilt, er solle in seinem Set an Standardkonvertierungen suchen, ob die gewählte Umwandlung unterstützt wird. Falls nicht, soll er gefälligst einen Fehler ausgeben. Bei der Klammer-Version wird einfach irgendwie versucht, einen Typ in einen anderen umzubiegen (was in C++ besser durch reinterpret_cast gelöst wird).

dooooomi

Nexus schrieb:

Man kann sich darüber streiten, aber wenn man ein blau hervorgehobenes Schlüsselwort sieht, erkennt man meiner Ansicht nach schneller, worum es sich handelt, als einfach bei zwei schwarzen Klammern, zumal Klammern ja sehr viele Bedeutungen haben können.

Wenn ein Typ zwischen öffnender und schließender Klammer steht, dann sehe ich auch sehr schnell, daß ich es mit einem Typecast zu tun habe (übrigens ein Grund, warum mir C-Style Casts lieber sind als Function-Style Casts).

Nexus schrieb:

Ja, du übersiehst, dass sehr wohl zusätzliche Information drinsteckt. Mit static_cast wird dem Compiler mitgeteilt, er solle in seinem Set an Standardkonvertierungen suchen, ob die gewählte Umwandlung unterstützt wird. Falls nicht, soll er gefälligst einen Fehler ausgeben. Bei der Klammer-Version wird einfach irgendwie versucht, einen Typ in einen anderen umzubiegen (was in C++ besser durch reinterpret_cast gelöst wird).

Wenn die jeweiligen Typen nicht bekannt wären, würde ich dir Recht geben. Aber auch in einer Welt voller Templates etc. gibt es noch genug Situationen, wo man es einfach nur mit einem int und einem float (o.ä.) zu tun hat, und wo auch niemals etwas anderes als ein elementarer Datentyp stehen wird.

Ein Cast von int nach float ist absolut eindeutig, sowohl für den Programmierer als auch für den Compiler gibt es da nichts was irgendwie mißverständlich sein könnte. Von daher hebe ich mir die expliziten *_cast<> lieber für die nicht-trivialen Fälle auf, wo man tatsächlich aufpassen muß was genau da passiert.

Nexus

dooooomi schrieb:

Wenn ein Typ zwischen öffnender und schließender Klammer steht, dann sehe ich auch sehr schnell, daß ich es mit einem Typecast zu tun habe (übrigens ein Grund, warum mir C-Style Casts lieber sind als Function-Style Casts).

Du kannst aber nicht bestreiten, dass man mit static_cast noch viel schneller sieht, dass ein Cast abläuft. Gerade wenn nicht-elementare Typen (seien es nur Typedefs wie size_t ) verwendet werden, reicht ein Blick schon nicht mehr. In einem komplexeren Ausdruck dann erst recht nicht. Zusätzlich erhält man bei static_cast sogar noch Information, dass es sich um eine Standardkonvertierung handelt.

dooooomi schrieb:

Ein Cast von int nach float ist absolut eindeutig, sowohl für den Programmierer als auch für den Compiler gibt es da nichts was irgendwie mißverständlich sein könnte. Von daher hebe ich mir die expliziten *_cast<> lieber für die nicht-trivialen Fälle auf, wo man tatsächlich aufpassen muß was genau da passiert.

Und wieso nicht immer den C++-Cast verwenden? Dann läuft man auch nicht Gefahr, die nicht-trivialen Fälle mit Klammercasts zu behandeln. Und weshalb "aufheben"? Die Anzahl der einsetzbaren C++-Casts ist nicht begrenzt.

Mal ehrlich: Findest du static_cast schlimm, weil es einige Zeichen mehr braucht? Casts kommen sowieso nicht sehr häufig vor, aber wenn, sollte einem die durch C++-Casts entstehende Sicherheit wert sein. Ist zumindest meine Meinung. Abgesehen davon finde ich es unschön, mal den einen C-Cast, mal die C++-Version zu verwenden.

asc

dooooomi schrieb:

Welchen Grund gibt es, für so etwas static_cast zu verwenden?

Für mich gibt es alleine schon zwei Gründe: Man kann besser nach casts suchen und man sieht sie leichter.

Nexus

In diesem Thread geht es übrigens auch gerade um diese Thematik.