Werte unter 1 und über 0

Hallo,

Ich versuche Folgendes und erhalte überall 0, was mache ich denn bitteschön falsch?!!

Achja, ich verwende Dec-C++.

Bin für jede Hilfe sehr Dankbar

cout << 1/2 << endl; // 0

float divide = 1/2;
cout << divide << endl; // 0

double divide_d = 1/2;
cout << divide_d << endl; // 0

DarkShadow44

cout << 1.0f/2 << endl; // 0.5

float divide = 1.0f/2;
cout << divide << endl; // 0.5

double divide_d = 1.0f/2;
cout << divide_d << endl; // 0.5

Der compiler sieht die Zahlen sonst als Integer an, und rundet entsprechend ab.

Deshalb musst du (nach nicht-variablen zahlen) ein "f" machen , aber NIE "1f" sondern "1.0f"

Dankeschön

Nun stellt sich mir die Frage:

Wie mach ich das ganze bei Variablen? :S

Habs rausgefunden, ich mach einfach:

var*1.0/var2

Danke nochmals

Nexus

DarkShadow44 schrieb:

Deshalb musst du (nach nicht-variablen zahlen) ein "f" machen , aber NIE "1f" sondern "1.0f"

1.f funktioniert auch und ich finde es persönlich schöner.

0.34waswarsnochgleich? schrieb:

Habs rausgefunden, ich mach einfach [...]

Für sowas gibt es Casts.

static_cast<float>(var1) / var2;

DarkShadow44

warum nicht

((float)var1) / var2;

drakon

DarkShadow44 schrieb:

warum nicht
((float)var1) / var2;

Das ist durchaus ein Streitfall. Man kann daran nicht mögen, dass es ein C-Style Cast ist und auch viele andere Sachen bedeuten könnte und somit anderst, als erwartet arbeiten kann. (Natürlich nicht in diesem Beispiel, aber Allgemein).
Dazu kommt noch das Argument, dass man, wenn man casts sucht diesen hier kaum auf die schnelle findet, während man den static_cast doch realtiv gut sieht und auch gut danach suchen kann.

Pro Argumente für den C-Style Cast fallen mir gerade keine ein. (gibts wahrscheinlich schon, aber ich bevorzuge halt auch die C++ Variante. ;))

Nexus

DarkShadow44 schrieb:

warum nicht
((float)var1) / var2;

Ich bevorzuge die C++-Casts, weil sie sicherer sind. Der C-Cast, den du verwendest, kann fast alles casten. Er beinhaltet die Funktionalität, die in C++ in die drei Operatoren static_cast , const_cast und reinterpret_cast aufgeteilt wurde. Das gleiche gilt übrigens für die Casts mit Konstruktor-Syntax, also float(var1) .

class Base {}; // polymorph
class Derived : public Base {};

const Base* p = ...;

// C-Cast umgeht Typsicherheit total, indem const weggecastet
// und der Zeigertyp gewaltsam umgebogen wird.
double** q = (double**) p; 

// C++-Cast: Ich sehe gleich: möglicherweise gefährliche Bitfrickelei.
const double** r = reinterpret_cast<const double**>(p);

// C++-Cast: Ich sehe gleich: Es wird ein CV-Qualifizierer entfernt.
Base* s = const_cast<Base*>(p);

// C++-Cast: Ich sehe gleich: Es erfolgt ein laufzeitgeprüfter Downcast.
const Derived* t = dynamic_cast<const Derived*>(p);

// C++-Cast: Ich sehe gleich: Eine statische Umwandlung kompatibler Typen wird 
// durchgeführt. Darüber, dass p hier tatsächlich auf ein Derived zeigt, bin ich
// mir als Benutzer von static_cast im Gegensatz zu dynamic_cast im Klaren.
const Derived* u = static_cast<const Derived*>(p);

Einige Leute sind der Ansicht, das wäre unnötig. Ich finde Typsicherheit jedoch was Tolles und bin froh, dass

auf diese Weise viele Fehler zur Kompilierzeit abgefangen werden
man anhand des Operatoren gleich sieht, auf welche Weise eine Typumwandlung erfolgt
ich nicht inkonsistent sein muss, indem ich je nach Laune C- mit C++-Casts mische

Du denkst vielleicht, beim float hier spielt es keine Rolle, da nicht wirklich was schiefgehen kann. Aber wo setzt man die Grenze? Es kann sehr schnell zu ungewollten Umwandlungen kommen, besonders im Zusammenhang mit Techniken wie Templates, Laufzeitpolymorphie oder Überladung, die von Typen abstrahieren. Das meine ich auch mit Konsistenz: Ich verwende durchgehend C++-Casts, damit ich nicht abwägen muss, wo eine Umwandlung harmlos genug für C-Casts ist, und damit ich auch auf Eventualitäten wie Refactoring mit minimaler Typänderung gerüstet bin.

Viele Leute stören sich ausserdem an der Länge der Schlüsselwörter. Ich zum Beispiel mag aber deren Aussagekraft. Im Idealfall sollten im Anwendungscode sowieso relativ wenige Casts vorkommen; diese können nach Möglichkeit in Funktionen ausgelagert werden. Oft ist dann durch den Funktionsnamen nochmals klarer, was getan wird.