In dem stdint.h (C99), boost/cstdint.hppund cstdint (C++0x)-Header gibt es unter anderem den Typ int32_t.
Gibt es ähnliche Fließkommatypen mit fester Größe? Etwas wie float32_t?
Fließkommatypen mit fester Größe
Lesezeit: 6 Minuten
9645400cookie-checkFließkommatypen mit fester Größe
Pietro
Nichts dergleichen existiert derzeit in den C- oder C++-Standards. Tatsächlich gibt es dafür nicht einmal eine Garantie float wird überhaupt ein binäres Fließkommaformat sein.
Einige Compiler garantieren, dass die float Typ ist das IEEE-754 32-Bit-Binärformat. Manche nicht. In Wirklichkeit, float ist in der Tat das IEEE-754 single tippe ein die meisten nicht eingebettete Plattformen, obwohl die üblichen Vorbehalte gegenüber einigen Compilern gelten, die Ausdrücke in einem breiteren Format auswerten.
Es gibt eine Arbeitsgruppe, die das Hinzufügen von C-Sprachbindungen für die Überarbeitung von IEEE-754 von 2008 diskutiert und die Empfehlung erwägen könnte, eine solche Typedef hinzuzufügen. Wenn dies zu C hinzugefügt würde, gehe ich davon aus, dass der C++-Standard nachziehen würde … schließlich.
-
Unabhängig davon, ob IEEE-754 oder nicht, es wird Endian-Portabilitätsprobleme immer noch nicht verhindern.
– Markus B
26. März 2010 um 16:56 Uhr
-
@Pietro: Das Ändern der Sprache hat keinen Einfluss auf Ihre Hardwarekompatibilität, es würde nur einige Hardware von der Konformität ausschließen. Wie würde eine IEEE FP-Garantie die Portabilität unterstützen?
– Kartoffelklatsche
26. März 2010 um 16:59 Uhr
-
@Potatoswatter: Es würde Hardwareanbieter ermutigen, konforme Lösungen anzubieten. Wenn Teil a Standard-C unterstützt, ohne Soft-Float-Bibliothekshacks zu benötigen, und Teil b dies nicht tut, ist das ein Marktvorteil für Teil a.
– Stefan Kanon
26. März 2010 um 17:04 Uhr
-
@Potatoswatter: (Fast) niemand kümmert sich um die Geschwindigkeit der Hardware. Wir kümmern uns um die Geschwindigkeit der Software, die auf der Hardware läuft. Software kann schneller sein, wenn die Hardware, auf der sie ausgeführt wird, Standards entspricht und die Software nicht 15 verschiedene Sonderfälle erkennen und reparieren muss, je nachdem, auf welcher Plattform sie ausgeführt wird.
– Stefan Kanon
26. März 2010 um 18:06 Uhr
-
Wie um alles in der Welt würden Sie bekommen besser Portabilität, indem verhindert wird, dass Ihr Code auf einer Reihe von Nischenarchitekturen kompiliert wird? Entweder verlassen Sie sich darauf, dass Floats IEEE sind, in diesem Fall wird Ihr Code dies tun bereits auf jeder IEEE-kompatiblen Implementierung laufen und sonst nichts, oder Sie tun es nicht, in diesem Fall läuft Ihr Code auf einer größeren Auswahl von Systemen. Wenn C++ garantiert IEEE-Konformität, Ihr Code würde nicht auf magische Weise portabler werden, Sie würden nur ausschließen, dass dies der Fall wäre je auf diesen nicht konformen Architekturen ausgeführt werden. Deine Logik ist komplett rückwärts.
– jalf
27. März 2010 um 1:18 Uhr
Kartoffelklatsche
Wenn Sie wissen wollen, ob Ihre float ist der IEEE 32-Bit-Typ, überprüfen Sie std::numeric_limits<float>::is_iec559. Es ist eine Kompilierzeitkonstante, keine Funktion.
Wenn Sie kugelsicherer sein möchten, überprüfen Sie dies auch std::numeric_limits<float>::digits um sicherzustellen, dass sie nicht heimlich den IEEE-Standard mit doppelter Genauigkeit für verwenden float. Es sollte 24 sein.
Wenn es darum geht long doublees ist wichtiger zu überprüfen digits weil es ein paar IEEE-Formate gibt, die vernünftigerweise sein könnten: 128 Bit (Ziffern = 113) oder 80 Bit (Ziffern = 64).
Es wäre nicht praktisch zu haben float32_t als solches, weil Sie normalerweise Floating-Point-Hardware verwenden möchten, falls verfügbar, und nicht auf eine Softwareimplementierung zurückgreifen möchten.
-
Die
long doubleFormat unter OS X (sowohl 32-Bit- als auch 64-Bit-Intel) ist genau das IEEE-754 Double Extended-Format, das in Little-Endian-Reihenfolge gespeichert wird. Daran ist überhaupt nichts funky. Die Bytes 0–7 enthalten das Signifikantenfeld, und die Bytes 8 und 9 enthalten die Exponenten- und Vorzeichenfelder.– Stefan Kanon
26. März 2010 um 20:03 Uhr
-
@Stephen: Das sind gute Neuigkeiten: v) . Stimmt das mit den Zahlen überein, die ich gepostet habe?
– Kartoffelklatsche
26. März 2010 um 20:21 Uhr
-
Denken Sie daran, dass Double Extended (im Gegensatz zu den anderen 754-Formaten) ein explizit führendes signifikantes Bit hat, also
5.0Lhat eine Bedeutung vona000000000000000. Sein unverzerrter Exponent ist +2, und die doppelt erweiterte Exponentenverzerrung ist3fffalso ist der voreingenommene Exponent für 5,0L4001. Das tatsächliche Bytemuster, wenn es in Little-Endian-Reihenfolge gespeichert wird, ist00 00 00 00 00 00 00 a0 01 40und wenn Sie das als zwei Little-Endian-64-Bit-Ganzzahlen betrachten, sehen Sie genau das, was Sie beobachtet haben.– Stefan Kanon
26. März 2010 um 20:38 Uhr
-
doppelt erweitert, wie von Intel in Hardware implementiert, das heißt. Das Double-Extended-Format ist nicht so festgelegt, wie es die beiden anderen Grundformate von IEEE-754 (1985) sind.
– Stefan Kanon
-
26. März 2010 um 20:52 Uhr
4001@Stephen: Da bin ich mir ziemlich sicher01 40 00 00 ...in Little-Endian ista0 01 40Wenn nichts anderes, kommt das niedrigstwertige Byte zuerst. Ich erwarte die Reihenfolgea0irgendwo in der Nummer erscheinen (wenn sie nur eine Rotation durchgeführt haben), aber ich glaube nicht, dass Sie erklärt haben, warum01 40undsind in völlig getrennten Hälften.
– Kartoffelklatsche
26. März 2010 um 22:08 Uhr
Wenn Sie der Meinung sind, dass Typedefs wie float32_t und float64_t aus irgendwelchen Gründen unpraktisch sind, müssen Sie sich zu sehr an Ihr vertrautes Betriebssystem, Ihren Compiler, gewöhnt haben, dass Sie nicht über Ihr kleines Nest hinausschauen können.
Es gibt Hardware, die nativ 32-Bit-IEEE-Gleitkommaoperationen ausführt, und andere, die 64-Bit ausführen. Manchmal müssen solche Systeme sogar miteinander sprechen, in diesem Fall ist es äußerst wichtig zu wissen, ob ein Double auf jeder Plattform 32-Bit oder 64-Bit ist. Wenn die 32-Bit-Plattform übermäßige Berechnungen auf der Grundlage der 64-Bit-Werte der anderen durchführen würde, möchten wir möglicherweise je nach Timing- und Geschwindigkeitsanforderungen auf die niedrigere Genauigkeit umwandeln.
-
Ich persönlich fühle mich unwohl bei der Verwendung von Floats und Doubles, es sei denn, ich weiß genau, wie viele Bits sie auf meiner Plattform haben. Umso mehr, wenn ich diese über einen Kommunikationskanal auf eine andere Plattform übertragen soll.
„Ich persönlich fühle mich unwohl bei der Verwendung von Floats und Doubles, wenn ich nicht genau weiß, wie viele Bits sie auf meiner Plattform haben. Noch mehr, wenn ich diese über einen Kommunikationskanal auf eine andere Plattform übertragen muss.“ – Sie meinen, Sie verwenden Textdateiformate? Bei diesen gibt es den Nachteil der Dateigröße: ein 32 Float benötigt 4 Bytes; diese in Textform können nur eine vierstellige Zahl darstellen…
– Pietro
1. April 2014 um 11:27 Uhr
decimal32
decimal64
decimal128
Derzeit gibt es einen Vorschlag, die folgenden Typen in die Sprache aufzunehmen: #include <decimal>die eines Tages zugänglich sein könnten
Warum braucht man so etwas?
– Khaled Alshaya
26. März 2010 um 16:08 Uhr
Sie brauchen so etwas, wenn Sie eine Datenstruktur mit einem Gleitkommawert haben und auch genau wissen möchten, wie groß sie ist.
– Pöbel
26. März 2010 um 16:26 Uhr
@mobrule: Wenn Sie nur wissen müssen, wie groß die Größe ist, verwenden Sie die
sizeofOperator. Ein Typ wie dieser wäre nützlich, wenn ein Algorithmus eine bekannte spezifische Größe erfordert.– Stefan Kanon
26. März 2010 um 16:33 Uhr
@Stephen Canon – ja, wenn Sie die Größe garantieren möchten. Angenommen, eine Instanz Ihrer Datenstruktur passt in 64 Bit und kann als Wert an eine externe Bibliothek übergeben werden.
– Pöbel
26. März 2010 um 17:37 Uhr
@StephenCanon Betrachten Sie eine plattformübergreifende Serialisierungsbibliothek. Wie kann
sizeofverwendet werden, um das Problem des konsistenten Marshalling und Unmarshalling von Floating-Typen zu lösen?– Kyle Strand
22. Juni 2015 um 20:39 Uhr