Sind die Typen von <cstdint> (wie zB int16_t , uint_fast64_t , int_least8_t ) garantiert typedef s für einen der eingebauten Typen wie short , unsigned long usw.?
Oder ist es einer Implementierung erlaubt, Typen zu verwenden, die nicht zu den üblichen gehören, um die Typen mit fester Breite zu implementieren?
Diese werden vom C-Standard spezifiziert (und durch den C ++ - Standard durch Bezugnahme eingeschlossen), der erfordert, dass jeder ein typedef für einen vorzeichenbehafteten Integer-Typ oder vorzeichenlosen Integer-Typ je nachdem.
signed integer type ist wiederum so definiert, dass die Kernsprache aus den Standard-Integer-Typen mit Vorzeichen besteht (die signed char , short int , int , long int und long long int ) und alle implementierungsdefinierten erweiterten signierten Integer-Typen .
Entsprechend wird vorzeichenloser Integer-Typ durch die Kernsprache definiert, die aus den standardmäßigen Ganzzahlarten ohne Vorzeichen besteht (die unsigned char , unsigned short int , unsigned int , unsigned long int und unsigned long long int ) und alle implementierungsdefinierten erweiterten vorzeichenlosen Ganzzahl-Typen , die den erweiterten Ganzzahl-Typen mit Vorzeichen entsprechen.
Kurz gesagt, jeder dieser typedefs kann einer der üblichen eingebauten Typen oder ein implementierungsdefinierter erweiterter Integer-Typ sein. Die meisten Compiler unterstützen keine erweiterten Integer-Typen, daher müssen sie bei diesen Compilern eingebaute Typen sein.
Nein, zumindest nicht für die Typen intN_t . Diese Typen haben garantiert eine Zweierkomplementdarstellung (gemäß C99 7.18.1.1, die Referenz C ++ 11 und C ++ 14). Und Standard-Integer-Typen müssen nicht Zweierkomplement sein.
C11 hat auch eine wichtige Änderung gegenüber C99 (was eigentlich nur Bugfix ist), was den obigen Punkt betont:
7.20.1.1/3:
Wenn jedoch eine Implementierung Integer-Typen mit bereitstellt Weiten von 8, 16, 32 oder 64 Bit, keine Padding-Bits, und (für die signierten Typen), die a Zweierkomplement-Darstellung , definiert sie die entsprechenden typedef-Namen.
Ich habe einen Entwurf der C99-Spezifikation vor mir und einen Entwurf der C ++ 14-Spezifikation. Da es sich um Entwürfe handelt, könnten diese Informationen falsch sein, aber ich glaube, dass der Wortlaut in der endgültigen Fassung derselbe ist.
In der C ++ 14-Spezifikation sagt § 18.4.1 Folgendes über <cstdint> :
Es sagt dann
Der Header definiert alle Funktionen, Typen und Makros wie im C-Standard 7.18.
Ich ging zum Entwurf des C99-Standards, §7.18, und sah nichts, was die definierten Typen benötigte, um Aliase für eingebaute Typen wie int , long int usw. zu sein. Es sagte nur, wenn diese Typen existieren Sie müssen bestimmte Beschränkungen hinsichtlich ihrer Bereiche, Größen und Speicherlayouts erfüllen.
Insgesamt vermute ich stark, dass die Antwort "nein" ist, aber wenn ich mich irre, interessiert mich, wo ich die Spezifikation falsch gelesen habe. : -)
Hoffe, das hilft!
Aus dem C ++ - Standard: "Es können auch implementation-defined, extended signed integer types vorhanden sein. Die Integer-Typen für Standard und Extended signed werden gemeinsam als Ganzzahlen mit Vorzeichen bezeichnet.". (Ich denke, es gibt eine ähnliche Zeile über erweiterte vorzeichenlose Integer-Typen.) Es wird nicht gesagt, wie Sie diese erweiterten Integer-Typen verwenden würden, sie sind offensichtlich nicht portierbar und die Implementierung ist definiert.
int16_t usw. kann jedoch typedefs für erweiterte Integer-Typen sein.
Tags und Links c++ language-lawyer