reinterpret_cast conversion

Konvertiert zwischen Typen durch Neuinterpretation des zugrundeliegenden Bitmusters.

Syntax

Gibt einen Wert vom Typ target-type zurück.

Erklärung

Im Gegensatz zu static_cast , aber ähnlich wie const_cast , generiert der reinterpret_cast -Ausdruck keine CPU-Befehle (außer bei der Konvertierung zwischen Ganzzahlen und Zeigern oder zwischen Zeigern auf obskuren Architekturen, bei denen die Zeigerdarstellung vom Typ abhängt). Es handelt sich primär um eine Compile-Time-Direktive, die den Compiler anweist, expression so zu behandeln, als hätte es den Typ target-type .

Nur die folgenden Konvertierungen können mit reinterpret_cast durchgeführt werden, außer wenn solche Konvertierungen Constness entfernen würden (oder Volatilität).

Wie bei allen Cast-Ausdrücken ist das Ergebnis:

• ein lvalue, falls target-type ein lvalue-Referenztyp ist oder ein rvalue-Referenztyp auf Funktionstyp (seit C++11) ;

• ein prvalue andernfalls.

Typaliasierung

Typzugänglichkeit

Wenn ein Typ T_ref ähnlich zu einem der folgenden Typen ist, ist ein Objekt vom dynamischen Typ T_obj typzugänglich durch einen Lvalue (bis C++11) Glvalue (seit C++11) vom Typ T_ref :

• char , unsigned char oder std::byte (seit C++17) : dies ermöglicht die Untersuchung der Objektdarstellung eines beliebigen Objekts als Byte-Array.
• T_obj
• der entsprechende vorzeichenbehaftete oder vorzeichenlose Typ zu T_obj

Wenn ein Programm versucht, den gespeicherten Wert eines Objekts durch einen lvalue (bis C++11) glvalue (seit C++11) zu lesen oder zu modifizieren, durch den es nicht typzugreifbar ist, ist das Verhalten undefiniert.

Diese Regel ermöglicht typbasierte Alias-Analyse, bei der ein Compiler annimmt, dass der über einen Glvalue eines Typs gelesene Wert nicht durch einen Schreibzugriff auf einen Glvalue eines anderen Typs verändert wird (vorbehaltlich der oben genannten Ausnahmen).

Beachten Sie, dass viele C++-Compiler diese Regel als nicht standardkonforme Spracherweiterung lockern, um Zugriffe mit falschem Typ über das inaktive Mitglied einer union zu erlauben (solche Zugriffe sind in C nicht undefiniert).

Aufrufkompatibilität

Wenn eine der folgenden Bedingungen erfüllt ist, ist ein Typ T_call call-compatible mit einem Funktionstyp T_func :

• T_call ist derselbe Typ wie T_func .

Wenn eine Funktion durch einen Ausdruck aufgerufen wird, dessen Funktionstyp nicht aufrufkompatibel mit dem Typ der Definition der aufgerufenen Funktion ist, ist das Verhalten undefiniert.

Hinweise

Vorausgesetzt, dass die Ausrichtungsanforderungen erfüllt sind, ändert ein reinterpret_cast den Wert eines Zeigers nicht, außer in einigen wenigen eingeschränkten Fällen, die zeigerinterkonvertierbare Objekte betreffen:

struct S1 { int a; } s1;
struct S2 { int a; private: int b; } s2; // nicht standard-layout
union U { int a; double b; } u = {0};
int arr[2];
int* p1 = reinterpret_cast<int*>(&s1); // Wert von p1 ist "Zeiger auf s1.a", weil
                                       // s1.a und s1 zeiger-interkonvertierbar sind
int* p2 = reinterpret_cast<int*>(&s2); // Wert von p2 wird durch reinterpret_cast nicht geändert
                                       // und ist "Zeiger auf s2". 
int* p3 = reinterpret_cast<int*>(&u);  // Wert von p3 ist "Zeiger auf u.a":
                                       // u.a und u sind zeiger-interkonvertierbar
double* p4 = reinterpret_cast<double*>(p3); // Wert von p4 ist "Zeiger auf u.b": u.a und
                                            // u.b sind zeiger-interkonvertierbar, weil
                                            // beide mit u zeiger-interkonvertierbar sind
int* p5 = reinterpret_cast<int*>(&arr); // Wert von p5 wird durch reinterpret_cast nicht geändert
                                        // und ist "Zeiger auf arr"

Das Ausführen eines Klassenmitgliederzugriffs, der auf einen nicht-statischen Datenelement oder eine nicht-statische Memberfunktion verweist, auf einen Glvalue, der tatsächlich kein Objekt des entsprechenden Typs bezeichnet - wie eines, das durch einen reinterpret_cast erhalten wurde - führt zu undefiniertem Verhalten:

struct S { int x; };
struct T { int x; int f(); };
struct S1 : S {};    // Standard-Layout
struct ST : S, T {}; // Kein Standard-Layout
S s = {};
auto p = reinterpret_cast<T*>(&s); // Wert von p ist "Zeiger auf s"
auto i = p->x; // Klassenmember-Zugriffsausdruck ist undefiniertes Verhalten;
               // s ist kein T-Objekt
p->x = 1; // Undefiniertes Verhalten
p->f();   // Undefiniertes Verhalten
S1 s1 = {};
auto p1 = reinterpret_cast<S*>(&s1); // Wert von p1 ist "Zeiger auf das S-Subobjekt von s1"
auto i = p1->x; // OK
p1->x = 1;      // OK
ST st = {};
auto p2 = reinterpret_cast<S*>(&st); // Wert von p2 ist "Zeiger auf st"
auto i = p2->x; // Undefiniertes Verhalten
p2->x = 1;      // Undefiniertes Verhalten

Viele Compiler geben in solchen Fällen "strict aliasing"-Warnungen aus, obwohl solche Konstrukte technisch gesehen mit etwas anderem als dem Abschnitt in Konflikt geraten, der allgemein als "strict aliasing rule" bekannt ist.

Der Zweck von striktem Aliasing und verwandten Regeln ist es, typbasierte Alias-Analyse zu ermöglichen, die zunichtegemacht würde, wenn ein Programm gültigerweise eine Situation erzeugen könnte, in der zwei Zeiger auf unabhängige Typen (z.B. ein int * und ein float * ) gleichzeitig existieren und beide verwendet werden könnten, um denselben Speicher zu laden oder zu speichern (siehe diese E-Mail im SG12-Reflector ). Daher ruft jede Technik, die scheinbar in der Lage ist, eine solche Situation zu erzeugen, notwendigerweise undefiniertes Verhalten hervor.

Wenn es notwendig ist, die Bytes eines Objekts als Wert eines anderen Typs zu interpretieren, std::memcpy oder std::bit_cast (seit C++20) können verwendet werden:

double d = 0.1;
std::int64_t n;
static_assert(sizeof n == sizeof d);
// n = *reinterpret_cast<std::int64_t*>(&d); // Undefiniertes Verhalten
std::memcpy(&n, &d, sizeof d);               // OK
n = std::bit_cast<std::int64_t>(d);          // ebenfalls OK

In C erfolgen Aggregat-Kopie und -Zuweisung Zugriff auf das Aggregat-Objekt als Ganzes. Aber in C++ werden solche Aktionen immer durch einen Member-Funktionsaufruf durchgeführt, der auf die einzelnen Subobjekte zugreift, anstatt auf das gesamte Objekt (oder, im Fall von Unions, kopiert die Objektrepräsentation, d.h. via unsigned char ).

Schlüsselwörter

reinterpret_cast

Beispiel

#include <cassert>
#include <cstdint>
#include <iostream>
int f() { return 42; }
int main()
{
    int i = 7;
    // Zeiger zu Ganzzahl und zurück
    std::uintptr_t v1 = reinterpret_cast<std::uintptr_t>(&i); // static_cast ist ein Fehler
    std::cout << "The value of &i is " << std::showbase << std::hex << v1 << '\n';
    int* p1 = reinterpret_cast<int*>(v1);
    assert(p1 == &i);
    // Funktionszeiger zu anderem und zurück
    void(*fp1)() = reinterpret_cast<void(*)()>(f);
    // fp1(); undefiniertes Verhalten
    int(*fp2)() = reinterpret_cast<int(*)()>(fp1);
    std::cout << std::dec << fp2() << '\n'; // sicher
    // Typ-Aliasing durch Zeiger
    char* p2 = reinterpret_cast<char*>(&i);
    std::cout << (p2[0] == '\x7' ? "This system is little-endian\n"
                                 : "This system is big-endian\n");
    // Typ-Aliasing durch Referenz
    reinterpret_cast<unsigned int&>(i) = 42;
    std::cout << i << '\n';
    [[maybe_unused]] const int &const_iref = i;
    // int &iref = reinterpret_cast<int&>(
    //     const_iref); // Compiler-Fehler - const kann nicht entfernt werden
    // Muss const_cast verwenden: int &iref = const_cast<int&>(const_iref);
}

The value of &i is 0x7fff352c3580
42
This system is little-endian
42

Fehlerberichte

Die folgenden verhaltensändernden Fehlerberichte wurden rückwirkend auf zuvor veröffentlichte C++-Standards angewendet.

Referenzen

Siehe auch