Was bedeutet "#INF"
-
Hallo,
ich berechne die Dauer einer Produktion in einem Spiel mit der folgenden Formel:time = (double) ((need - have) / (double) (prod/3600));
Danach wird dann noch auf Minuten/Stunden umgerechnet, aber da der Fehler bereits vorher sichtbar ist, wird es damit nicht(s) zu tun haben.
Nach der Eingabe von...
need = 15000
have = 10000
prod = 3500... erhalte ich als Ausgabe der Dauer "1.#INF".
Wer kann mir bei diesem Problem weiterhelfen? Es sollen ganz normal die Dezimalstellen (im o. g. Fall inkl. Umrechnung: 1,428...) angezeigt werden.
PS: Lasse ich oben bei der Formel ein DOUBLE-Typecasting weg, bricht das Programm ab (Win möchte Fehleranalyse machen/senden).
-
need und have sowie prod sind nicht zufällig integrale Typen? Dann wird hinten in der Klammer nämlich int / int gerechnet und dann erst nach double gecastet. Dabei kommt wahrscheinlich eine Division durch 0 raus, was zu dem geschilderten Absturz führt.
-
Überfordert schrieb:
time = (double) ((need - have) / (double) (prod/3600));
probier mal so:
time = (need - have) / (double)prod / 3600.0;
-
@LordJaxom: Peinlich, peinlich ... das mit den INT-Typen (waren/sind sie tatsächlich) und dem daraus folgenden Divisionsproblem hatte ich ganz übersehen.
Habe es nun zwar etwas anders gelöst, als dein Vorschlag "net", aber nun funktioniert es.
Vielen Dank an euch beide [
], manchmal sieht man echt den sprichwörtlichen Wald vor lauter Bäumen nicht.
-
net schrieb:
probier mal so:
time = (need - have) / (double)prod / 3600.0;
Ist das nicht besser?
time = (need - have) / static_cast<double>(prod) / 3600.0;
-
Chris++ schrieb:
net schrieb:
probier mal so:
time = (need - have) / (double)prod / 3600.0;
Ist das nicht besser?
time = (need - have) / static_cast<double>(prod) / 3600.0;
besser? welchen vorteil hat denn dein code?
-
ich hab noch eine:
time = (need - have) / double(prod) / 3600.0;
alle drei varianten haben dieselbe bedeutung.
-
net schrieb:
Chris++ schrieb:
net schrieb:
probier mal so:
time = (need - have) / (double)prod / 3600.0;
Ist das nicht besser?
time = (need - have) / static_cast<double>(prod) / 3600.0;
besser? welchen vorteil hat denn dein code?
Er verwendet die C++ Casts, während du noch mit den C Casts rumgurkst, unnötigerweise. Die C++ Casts haben den Vorteil, dass es für jeden Zweck einen gibt (static, dynamic, reinterpret, const). Das macht klar, wie gecastet werden soll (was auch die Fehlersuche erleichtern dürfte), ein C Cast hingegen castet irgendwie.
Daher: In C++ die neuen Casts verwenden!MfG
GPC
-
camper schrieb:
ich hab noch eine:
time = (need - have) / double(prod) / 3600.0;
alle drei varianten haben dieselbe bedeutung.
aber meine ist die einzige, die unter c wie auch unter c++ funzt
-
net schrieb:
camper schrieb:
ich hab noch eine:
time = (need - have) / double(prod) / 3600.0;
alle drei varianten haben dieselbe bedeutung.
aber meine ist die einzige, die unter c wie auch unter c++ funzt
relevanz?
-
GPC schrieb:
Er verwendet die C++ Casts, während du noch mit den C Casts rumgurkst, unnötigerweise. Die C++ Casts haben den Vorteil, dass es für jeden Zweck einen gibt (static, dynamic, reinterpret, const)...
ich glaube dass die meisten c++ casts verwenden, nur weil's schicker/neuer/schöner aussieht. kennst du ein beispiel das nur mit c++ casts funktioniert und mit c casts nicht?
-
Alle dynamic_casts?!
-
fast. alle dynamic_casts, die einen polymorphen typ benötigen. es war ja nie der sinn der 'neuen' cast syntax, neue konvertierungen einzuführen. die, die wir haben, bereiten schon genug kopfzerbrechen.
-
net schrieb:
GPC schrieb:
Er verwendet die C++ Casts, während du noch mit den C Casts rumgurkst, unnötigerweise. Die C++ Casts haben den Vorteil, dass es für jeden Zweck einen gibt (static, dynamic, reinterpret, const)...
ich glaube dass die meisten c++ casts verwenden, nur weil's schicker/neuer/schöner aussieht.
Nun ja, ich fand die neuen Casts zu Beginn ja echt hässlich, inzwischen geht's einigermaßen. Daran liegt's wohl eher nicht. Und wenn ich ehrlich bin, verwende ich schon C++ Sprachmittel, wenn's welche gibt. Warum auch nicht? Ich programmiere ja schließlich C++ und nicht C (Äquivalent zu dieser Situation wäre die #define und const Geschichte).
kennst du ein beispiel das nur mit c++ casts funktioniert und mit c casts nicht?
Die Frage wurde ja bereits beantwortet. Sie sind einfach klarer im Vergleich zu C Casts. Siehe auch Lektion 2 von MEC++ von Scott Meyers.
MfG
GPC
-
GPC schrieb:
Er verwendet die C++ Casts, während du noch mit den C Casts rumgurkst, unnötigerweise. Die C++ Casts haben den Vorteil, dass es für jeden Zweck einen gibt (static, dynamic, reinterpret, const). Das macht klar, wie gecastet werden soll (was auch die Fehlersuche erleichtern dürfte), ein C Cast hingegen castet irgendwie.
Daher: In C++ die neuen Casts verwenden!Genau deswegen.
-
Vielleicht erbarmt sich doch mal jemand und schreibt einen FAQ Beitrag...
Greetz, Swordfish
-
GPC schrieb:
kennst du ein beispiel das nur mit c++ casts funktioniert und mit c casts nicht?
Die Frage wurde ja bereits beantwortet. Sie sind einfach klarer im Vergleich zu C Casts. Siehe auch Lektion 2 von MEC++ von Scott Meyers.
aber kann nicht mal jemand einen codebeispiel posten, das nur mit c++-casts geht und mit c-casts z.b. abstürzt oder sich anders verhält?
-
class a { public: virtual ~a() {} }; class b : public a { }; class c : public a { }; void test() { b B; a *A = &B; // C-Cast: undefiniertes Verhalten c *C = (c *) A; // C++ Cast: 0-Zeiger wird zurückgegeben c *C = dynamic_cast<c *> (A); }
-
danke.
geht aber nur wen rtti enabled ist, sonst stürzt es ab beim dynamic_cast (bei mir zumindestens). also einen dynamic_cast kann man nicht durch c-casts ersetzen, aber wie ist es z.b. mit static_cast und reinterpret_cast? habt ihr dafür auch beispiele, die zeigen dass man sie in c++ nicht durch c-casts ersetzen kann?
-
net schrieb:
habt ihr dafür auch beispiele, die zeigen dass man sie in c++ nicht durch c-casts ersetzen kann?
es gibt ein paar seltene fälle. nähmlich dann wenn ein static_cast oder ein reinterpret_cast erlaubt wären (in dem falle verhält sich C-cast wie ein static_cast) und wir ein reinterpret_cast benötigen.
// wir wollen viele verschieden (POD-)Ts binär in einem stream speichern. weil das ewige gecaste beim user unschön ist, schreiben wir eine template-klasse. verschiedene versionen: // 1 (C-style cast über pointer) template<typename T> bool write_binary(std::ostream& s, const T& arg) { return s.write( (const char*)&arg, sizeof arg ); }; // 2 (reinterpret_cast über pointer) template<typename T> bool write_binary(std::ostream& s, const T& arg) { return s.write( reinterpret_cast< const char* >( &arg ), sizeof arg ); }; // 3 (C-style cast über array) template<typename T> bool write_binary(std::ostream& s, const T& arg) { return s.write( (const char (&)[sizeof arg])arg, sizeof arg ); }; // 4 (static_cast über array) template<typename T> bool write_binary(std::ostream& s, const T& arg) { return s.write( static_cast< const char (&)[sizeof arg] >( arg ), sizeof arg ); }; // 5 (reinterpret_cast über array) template<typename T> bool write_binary(std::ostream& s, const T& arg) { return s.write( reinterpret_cast< const char (&)[sizeof arg] >( arg ), sizeof arg ); };
varianten 1 und 2 funktionieren, vorausgesetzt, T hat keinen falsch überladenen & operator - das wird wohl meist der fall sein, aber wenn wir können, sollten wir versuchen, nicht davon abhängig zu sein. variante 4 funktioniert nur, wenn T einen passenden konvertierungsoperator hat (oder zufällig mal bereits so ein array ist). variante 5 wird immer das tun, was wir wollen. und variante 3 entspricht variante 4, wenn diese zulässig ist (wir wissen aber nicht, was der konvertierungsoperator in 4 anstellt, wenn er existiert), sonst variante 5. dieser schleichende bedeutungswandel spricht in solchen fällen immer gegen C-style casts.