Abrunden in c++

[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.

1. ja, "pumukel" ist grundfalsch
2. 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

[Glühbirne]

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!