Abrunden in c++

icarus2

So müsste es doch gehen:

#include <iostream> 
#include <conio.h> 
#include <math.h> 

using namespace std; 

int main() 
{       
    double a = 728308.58; 
    a = floor(a);
	cout << a << endl;

	getch(); 
}

Das mit dem mal 100, dann abrunden und dann wieder teil durch 100 macht man, wenn man z.B. auf 2 Nachkommastellen genau runden möchte.

Tachyon schrieb:

Tut aber auch was komplett anderes.

Soweit ich ihn verstanden habe, will er das Ergebnis abgerundet bekommen - immer. Ohne weitere Spezifikation heißt das für mich: kill den Nachkommateil. Und so sollte es funzen.

pumuckl

Glühbirne schrieb:

int a=(int)floor(728308.58);

Das ist mal absolut unnötig komplex und blödsinnig.
- wenn schon casten, dann bitte mit C++-Casts, nicht mit dem C-Cast.
- wenn du den double einem int zuweist, brauchst du nicht explizit zu casten, das geschieht automatisch.
- Wenn der OP den Wert als double erhalten will, ist der Cast zum int Unsinn, dann reicht floor.
- Wenn der OP den Wert als int erhalten will, ist floor unnötig, es reicht die einfache Zuweisung, weil die Konvertierung die Nachkommastellen sowieso verwirft.

Belli

Nach dem Eingangspost hätte man schon davon ausgehen können, dass er auf zwei Nachkommastellen abrunden will.

pumuckl schrieb:

Das ist mal absolut unnötig komplex und blödsinnig.
- wenn schon casten, dann bitte mit C++-Casts, nicht mit dem C-Cast.
- wenn du den double einem int zuweist, brauchst du nicht explizit zu casten, das geschieht automatisch.
- Wenn der OP den Wert als double erhalten will, ist der Cast zum int Unsinn, dann reicht floor.
- Wenn der OP den Wert als int erhalten will, reicht die einfache Zuweisung, weil die Konvertierung die Nachkommastellen sowieso verwirft.

Dachte ich auch, bis mir mein Compiler gestern eine Fehlermeldung rausgehauen hat, weil die implizite Typumwandlung eben nicht durchgeführt wurde. Ein total depperter Fehler, die beiden Typen hätten ohne Probleme ineinander konvertierbar sein sollen, und trotzdem ...

Deshalb schreibe ich lieber explizite Casts. Wo du allerdings recht hast, ist, dass ich static_cast hätte verwenden können.

CStoll

Afaik geben Compiler eine Warnung heraus, wenn du eine möglicherweise verlustbehaftete Konvertierung (z.B. double->int) durchführen willst. Aber wenn du nicht mit der Option "betrachte Warnungen als Fehler" (o.ä.) compilierst, sollte das keine weiteren Konsequenzen haben.

FlorianB

@ pumuckel:
ich hab des so bei google gefunden.

wenn ich

double i = 728308.958;
int a=(int)floor(i);
cout << a;

verwende funktioniert es.

ich hab vergessen zu erwähnen, dass ich die Nachkommastellen weg haben möchte!
aba das tut es ja jetzt.

@ pumukel:
ist das jetzt falsch so?
also ich bin damit zufrieden.

thx

MfG flo

icarus2

Den int-cast brauchst du nicht explizit zu schreiben, so geht auch:

double i = 728308.958; 
	int a= floor(i); 
	cout << a << endl;

Brauchst du wirklich eine neue int-Variable? Schau dir mal meinen Code weiter oben an. Es ist nicht zwingend notwendig eine neue Variable einzuführen. Aber wenn du sie brauchst, dann ist das IMHO in Ordnung.

FlorianB schrieb:

ist das jetzt falsch so?

pumuckel wollte damit sagen, dass man es nicht verkomplizieren soll. Wenn du es als Ganzzahl willst, dann so:

double i = 1.23;
int a=i; // Warnung, da Informationsverlust.

// und wenn du die Warnung nicht willst, dann kannst du explizit casten. Nun weiß der Compiler, dass dir der Informationsverlust bewusst und schnuppe ist.
a=static_cast<int>(i);

Tachyon

Was willst Du denn haben? Ein Integer, oder ein Float ohne Nachkommanateil? Das ist ein Riesenunterschied.

FlorianB

nen Integer wert ohne nachkommastellen!
aber es funktioniert ja jetzt.
MfG flo

berniebutt

Ein float nach integer rundet ab, schmeisst also die Nachkommastellen weg. Wenn du dann den integer wieder auf float zuweist, hast du das gewünschte. Für mehr kannst du meine Funktion round von meiner HP berniebutt@npage.de herunterladen und nach deinen Bedürfnissen anpassen.

pumuckl

CStoll schrieb:

Afaik geben Compiler eine Warnung heraus, wenn du eine möglicherweise verlustbehaftete Konvertierung (z.B. double->int) durchführen willst. Aber wenn du nicht mit der Option "betrachte Warnungen als Fehler" (o.ä.) compilierst, sollte das keine weiteren Konsequenzen haben.

Okay, zugegeben. Da ich die Meinung vertrete, dass Code absolut warnungsfrei sein sollte, fällt die implizite Konvertierung also weg.
bleiben immernoch die Puntke, dass entweder der Cast oder der Aufruf von floor() unnötig sind, je anch Zieltyp. Und der C-Cast ist auch unschön.

Also eins von folgenden beiden:

double i = 728308.958;
int a = static_cast<int>(i); //Zieltyp int
double d = std::floor(i); //Zieltyp double

FlorianB schrieb:

@ pumuckel:
ich hab des so bei google gefunden.

Und einfach ohne drüber nachzudenken den Code benutzt? Wenn du den begleitenden Code gelesen hättest, wüsstest du, dass der Code alles bis auf zwei Nachkommastellen wegschneidet, was nicht ganz das ist, was du möchtest. Du solltest den Code zumindest verstehen, den du dir kopierst. Dazu gehört, dass du nachschlägst, was Funktionen, die du noch nicht kennst (floor z.B.) machen und wie man sie richtig verwendet.

wenn ich
double i = 728308.958;
int a=(int)floor(i);
cout << a;
verwende funktioniert es.

Es funktioniert, ist aber wie oben beschrieben überflüssig kompliziert.

@ pumukel:
ist das jetzt falsch so?
also ich bin damit zufrieden.

ja, "pumukel" ist grundfalsch
Der Code funktioniert, ist aber alles andere als schön, bewegt sich also irgeendwo in der Grauzone zwischen "richtig" und "falsch". Zufrieden wäre ich damit nicht

pumuckl schrieb:

[Okay, zugegeben. Da ich die Meinung vertrete, dass Code absolut warnungsfrei sein sollte, fällt die implizite Konvertierung also weg.
bleiben immernoch die Puntke, dass entweder der Cast oder der Aufruf von floor() unnötig sind, je anch Zieltyp. Und der C-Cast ist auch unschön.

Hier scheiden sich die Geister. Ich definiere "unschön" als etwas, was unnötig oder redundant ist, unangenehme Seiteneffekte haben kann oder veraltet ist. Unangenehme Seiteneffekte haben beide Casts (soweit ich weiß, aber ich bin immer bereit zu lernen) nicht, aber der static_cast ist länger zu tippen, während der C-Cast veraltet ist. Was soll man da nehmen?

Da ich außerdem viel in C programmiere, kann es mir tatsächlich schon mal passieren, dass einige wenige sprachliche Elemente aus C in C++ rutschen. Kein malloc oder print , eher diese Cast-Sache.

berniebutt

'unschön' ist nur ein Programmcode, der nicht das tut, was man will!
Für alles andere gibt es Lösungen, entweder mit Standardfunktionen oder mit eigenen Funktionen. Wo sind wir mit dieser Frage gelandet?

pumuckl

Glühbirne schrieb:

Hier scheiden sich die Geister. Ich definiere "unschön" als etwas, was unnötig oder redundant ist, unangenehme Seiteneffekte haben kann oder veraltet ist.

Deckt sich in etwa mit meinem Verständnis von "unschön" - wobei Aspekte der Lesbarkeit und Wartbarkeit noch dazukommen (Namen, Einrückung, Codeorganisation allgemein...)

Unangenehme Seiteneffekte haben beide Casts (soweit ich weiß, aber ich bin immer bereit zu lernen) nicht, aber der static_cast ist länger zu tippen, während der C-Cast veraltet ist. Was soll man da nehmen?

Der C-Cast hat in diesem Fall keine unangenehmen Seiteneffekte. Kann er aber in anderen, durchaus auch ähnlichen Situationen haben. Weil er eben nicht nur wie ein static_cast, sondern auchnoch wie dynamic_cast, reinterpret_cast usw. zusammen wirkt. Das ist einer der Hauptgründe warum in C++ die anderen Casts eingeführt wurden und warum man sie auch benutzen sollte.
Veraltet ist er auch, das ist das nächste Argument dagegen.
Dass static_cast länger zu tippen ist, ist kein Argument. Einfach weil man Code im Normalfall einmal tippt, aber zigmal liest. Und 13 Zeichen mehr zu tippen sind nun wirklich nicht die Welt. Dagegen ist die Lesbarkeit mit static_cast doch deutlich besser als mit C-Cast. Die C++-Casts sind nicht ohne Grund so lang zu tippen, denn durch die ausgeschriebenen Worte (am Besten mit Syntax-Highlighting) erkennt man schnell, dass da explizit was gemacht wird, wo z.B. wie hier willentlich die Genauigkeit von double verworfen wird. Grade bei längerem Code flutscht ein C-Cast beim überfliegen gerne mal durch und man muss ziemlich genau hinschauen, wo aus dem double plötzlich ein int gemacht wurde - beim static_cast springt die Stelle sofort ins Auge

berniebutt schrieb:

'unschön' ist nur ein Programmcode, der nicht das tut, was man will!
Für alles andere gibt es Lösungen, entweder mit Standardfunktionen oder mit eigenen Funktionen. Wo sind wir mit dieser Frage gelandet?

Code, der nicht tut was man will, ist schlichtweg falsch. "Unschön" im Hinsicht auf C++-Code ist eine Zusammenfassung von "nicht sicher", "nicht portabel", "nicht performant", "nicht gut designed", "nicht lesbar/wartbar". Der nächste Schritt wäre dann "unelegant", wobei es nicht für jedes Problem eine wirklich elegante Lösung gibt - und Eleganz ist Geschmackssache

Tachyon

Glühbirne schrieb:

[[...]Ich definiere "unschön" als etwas, was unnötig oder redundant ist, unangenehme Seiteneffekte haben kann oder veraltet ist.[...]

Das trifft alles auf C-Casts zu.

CStoll

pumuckl schrieb:

Der C-Cast hat in diesem Fall keine unangenehmen Seiteneffekte. Kann er aber in anderen, durchaus auch ähnlichen Situationen haben. Weil er eben nicht nur wie ein static_cast, sondern auchnoch wie dynamic_cast, reinterpret_cast usw. zusammen wirkt. Das ist einer der Hauptgründe warum in C++ die anderen Casts eingeführt wurden und warum man sie auch benutzen sollte.

Wie ein dynamic_cast wird der C-Cast bestimmt nicht arbeiten, aber ansonsten kannst du je nach Situation alle C++ Casts (eventuell auch in Kombination) damit meinen.

berniebutt

pumuckl schrieb:

berniebutt schrieb:

'unschön' ist nur ein Programmcode, der nicht das tut, was man will!
Für alles andere gibt es Lösungen, entweder mit Standardfunktionen oder mit eigenen Funktionen. Wo sind wir mit dieser Frage gelandet?

Code, der nicht tut was man will, ist schlichtweg falsch. "Unschön" im Hinsicht auf C++-Code ist eine Zusammenfassung von "nicht sicher", "nicht portabel", "nicht performant", "nicht gut designed", "nicht lesbar/wartbar". Der nächste Schritt wäre dann "unelegant", wobei es nicht für jedes Problem eine wirklich elegante Lösung gibt - und Eleganz ist Geschmackssache

Hallo pumuckl!

Stimmt. Ein Programmcode, der nicht das tut was man will ist falsch weil unbrauchbar! Die genannten weiteren Gesichtspunkte sind schon nachrangig einzustufen. Erst wenn es Probleme mit der Portabilität, den beanspruchten Ressourcen, der Performance, oder der Erweiterbar gibt, sollt man über die sicher gefundene Lösung nachdenken.

Jedem das Seine in Sachen Design, Eleganz, etc.

Die gestellte Frage lässt sich in reinem C sauber und zuverlässig lösen. C++ braucht man da nicht notwendig und kann die Dinge eher unnötig aufblasen!