Portierung Code
-
dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert
Der Standard legt sich schon ganz allgemein auf Darstellungen fest
this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types.
-
Moment camper, dein Zitat stimmt doch gar nicht - es ist Paragraph 7.20.1.1.
-
Arcoth schrieb:
dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert
Der Standard legt sich schon ganz allgemein auf Darstellungen fest
this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types.
Arcoth.
Plural != Singular.
Ja, der Standard legt sich ganz allgemein auf Darstellungen fest. Was bringt mir das wenn ich nicht dreifach Code schreiben will?
-
Hm, das ist mir noch nicht ganz klar.
Wenn ein int32_t also ein 32 bit integer mit two's complement ist, ist dann auch das Verhalten bei overflow und underflow definiert?#include <cstdio> #include <cstdint> void func(std::int32_t i) { if(i > i+1) std::fputs("overflow\n", stdout); else std::fputs("no overflow\n", stdout); }
compiler output:
main.cpp: In function 'void func(int32_t)': main.cpp:6:11: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow] if(i > i+1) ^
Ist die Warnung richtig oder falsch?
Laut assembler-output wird overflow hier wegoptimiert.
-
Der C++ Standard garantiert Overflow-Verhalten nur für unsigned Typen.
Ob es da für dieintXX_t
ne Spezialregelung gibt, weiss ich nicht. camper wird's wissen
-
Arcoth schrieb:
Moment camper, dein Zitat stimmt doch gar nicht - es ist Paragraph 7.20.1.1.
naja fasst, wollte C99 schreiben, und hatte schon C11 aufgeschlagen
-
hustbaer schrieb:
Der C++ Standard garantiert Overflow-Verhalten nur für unsigned Typen.
Ob es da für dieintXX_t
ne Spezialregelung gibt, weiss ich nicht. camper wird's wissenEine Spezialregelung wäre seltsam - zumal ja viele Rechnungen sowieso erst eine Promotion erfordern, bei denen dann eine solche Regelung ins Leere laufen würde. also: gibt's nicht
-
Ist dann nicht die two's complement Bedingung relativ sinnlos?
-
Flashput schrieb:
Ist dann nicht die two's complement Bedingung relativ sinnlos?
wieso? Zweikomplement sagt etwas aus über die Darstellung (Repräsentation) negativer Zahlen und entsprechend den Wertebereich des Typs. Die Repräsentation ist nat. nur relevant, wenn der Typ mal byteweise gelesen wird oder durch den zugehörigen vorzeichenlosen Typen. Zweikomplement hat den Vorteil das Letzteres tatsächlich zum gleichen Ergebnis führt wie eine normale Konvertierung.
Also
int32_t x = -42; // irgendwas negatives uint32_t y = x; auto z = reinterpret_cast<uint32_t&>(x); assert(y==z); // nur bei Zweierkomplement
in der umgekehrten Richtung steht wieder im Weg, dass die Konvertierung von vorzeichenlos in vorzeichenbehaftet implementation-defined ist, könnte also schiefgehen, praktisch wird es das nicht.
-
@camper
Wenn dann würde es natürlich nur Sinn machen, wenn von Plattformen dieintXX_t
Typen anbieten verlangt wird, dass alle Integer-Typen das gewohnte Two's-Complement Überlaufverhalten zeigen.
Und auch alle Konvertierungen.