Eine Reihe von Compilern bietet 128-Bit-Integer-Typen, aber keiner der von mir verwendeten bietet die typedefs int128_t. Wieso den?
Soweit ich mich erinnere ist der Standard
- Reserven
int128_t für diesen Zweck
- Ermutigt Implementierungen, die einen solchen Typ bereitstellen, die typedef . bereitzustellen
- Mandate, die solche Implementierungen bieten
intmax_t von mindestens 128 Bit
(und ich glaube nicht, dass ich eine Implementierung verwendet habe, die tatsächlich dem letzten Punkt entspricht)
Ich beziehe mich auf den C-Standard; Ich denke, der C++-Standard erbt die Regeln für <stdint.h> / <cstdint> von C.
Ich weiß, dass gcc 128-Bit-Ganzzahlen mit und ohne Vorzeichen implementiert, mit den Namen __int128 und unsigned __int128 (__int128 ist ein implementierungsdefiniertes Schlüsselwort) auf einigen Plattformen.
Selbst für eine Implementierung, die einen standardmäßigen 128-Bit-Typ bereitstellt, bietet der Standard keine erfordern int128_t oder uint128_t zu definieren. Zitieren von Abschnitt 7.20.1.1 der N1570 Entwurf der C-Norm:
Diese Typen sind optional. Wenn eine Implementierung jedoch Integer-Typen mit Breiten von 8, 16, 32 oder 64 Bit, keine Füllbits und (bei den vorzeichenbehafteten Typen) mit einer Zweierkomplement-Darstellung bereitstellt, muss sie die entsprechenden typedef-Namen definieren.
C erlaubt Implementierungen zu definieren erweiterte Integer-Typen deren Namen implementierungsdefinierte Schlüsselwörter sind. gccs __int128 und unsigned __int128 sind den vom Standard definierten erweiterten Integer-Typen sehr ähnlich — aber gcc behandelt sie nicht so. Stattdessen werden sie als Spracherweiterung behandelt.
Insbesondere wenn __int128 und unsigned __int128 war erweiterte Integer-Typen, dann müsste gcc definiert werden intmax_t und uintmax_t als diese Typen (oder als einige Typen mindestens 128 Bit breit). Es tut dies nicht; stattdessen, intmax_t und uintmax_t sind nur 64 bit.
Das ist meiner Meinung nach bedauerlich, aber ich glaube nicht, dass es gcc nicht konform macht. Kein tragbares Programm kann von der Existenz von abhängen __int128, oder auf einem ganzzahligen Typ, der breiter als 64 Bit ist. Und ändern intmax_t und uintmax_t würde ernsthafte ABI-Kompatibilitätsprobleme verursachen.
.
Der Standard schreibt das nirgends vor
__int128muss als “erweiterter Integer-Typ” behandelt werden.– TC
14. April ’15 um 22:53
Welche Sprache verwendest du? Ich bin mir ziemlich sicher, dass der C++-Standard nicht sagt
intmax_tmuss mindestens 128 Bit lang sein, und ich bezweifle, dass der C-Standard dies auch tut.– Brian Bi
14. April ’15 um 22:54
@Hurkyl: richtig, die Tatsache, dass die Implementierung ein Ding namens . bereitstellt
__int128das sich wie eine ganze Zahl verhält, bedeutet nicht, dass es “wirklich” in dem Sinne ist, dassintmax_tkümmert sich um. Auf der anderen Seite, wenn die Implementierung bereitgestellt wurdeint128_t, dannintmax_tmüsste mindestens so groß sein. Eine mögliche Erklärung ist also, dass die Implementierungen den Typ nicht wollenintmax_tändern, wenn Compiler-spezifische Erweiterungen deaktiviert sind, aber ich habe keine Ahnung, ob das der wahre Grund ist oder nicht.– Steve Jessop
14. April ’15 um 22:57
Wenn der Compiler bietet einen erweiterten Integer-Typ, dann
intmax_t(oderuintmax_t, ggf.) muss diese darstellen können. Der Compiler kann aber auch einen Typ bereitstellen, der kein erweiterter Integer-Typ ist, sich aber ähnlich den Integer-Typen verhält. Und was ändernintmax_tEs wird ABI brechen, also behandelt kein Compiler wirklich__int128als erweiterter Integer-Typ.– TC
14. April ’15 um 22:59
@TC: Das ist schade. Meiner Meinung nach verfehlt es den Zweck von
intmax_t. C-Code sollte nicht davon abhängen, dass er eine bestimmte Breite hat.– Keith Thompson
14. April ’15 um 23:19