reinterpret_cast conversion

Convertit entre les types en réinterprétant le motif de bits sous-jacent.

Syntaxe

Retourne une valeur de type target-type .

Explication

Contrairement à static_cast , mais comme const_cast , l'expression reinterpret_cast ne compile en aucune instruction CPU (sauf lors de conversions entre entiers et pointeurs, ou entre pointeurs sur des architectures obscures où la représentation des pointeurs dépend de leur type). Il s'agit principalement d'une directive à la compilation qui indique au compilateur de traiter expression comme s'il avait le type target-type .

Seules les conversions suivantes peuvent être effectuées avec reinterpret_cast , sauf lorsque ces conversions supprimeraient la constance (ou la volatilité).

Comme pour toutes les expressions de cast, le résultat est :

• un lvalue si target-type est un type référence lvalue ou une référence rvalue vers un type fonction (depuis C++11) ;

• un prvalue sinon.

Alias de type

Accessibilité des types

Si un type T_ref est similaire à l'un des types suivants, un objet de type dynamique T_obj est accessible par type via une lvalue (jusqu'en C++11) glvalue (depuis C++11) de type T_ref :

• char , unsigned char ou std::byte (depuis C++17) : cela permet d'examiner la représentation objet de tout objet comme un tableau d'octets.
• T_obj
• le type signé ou non signé correspondant à T_obj

Si un programme tente de lire ou de modifier la valeur stockée d'un objet via un lvalue (jusqu'à C++11) glvalue (depuis C++11) via lequel il n'est pas accessible par le type, le comportement est indéfini.

Cette règle active l'analyse d'alias basée sur les types, dans laquelle un compilateur suppose que la valeur lue via une glvalue d'un type n'est pas modifiée par une écriture vers une glvalue d'un type différent (sous réserve des exceptions mentionnées ci-dessus).

Notez que de nombreux compilateurs C++ assouplissent cette règle, via une extension de langage non standard, pour autoriser l'accès avec un type incorrect via le membre inactif d'une union (un tel accès n'est pas indéfini en C).

Compatibilité des appels

Si l'une des conditions suivantes est satisfaite, un type T_call est compatible d'appel avec un type de fonction T_func :

• T_call est du même type que T_func .

Si une fonction est appelée via une expression dont le type de fonction n'est pas compatible avec le type de la définition de la fonction appelée, le comportement est indéfini.

Notes

En supposant que les exigences d'alignement soient satisfaites, un reinterpret_cast ne modifie pas la valeur d'un pointeur en dehors de quelques cas limités traitant des objets pointer-interconvertible :

struct S1 { int a; } s1;
struct S2 { int a; private: int b; } s2; // pas standard-layout
union U { int a; double b; } u = {0};
int arr[2];
int* p1 = reinterpret_cast<int*>(&s1); // la valeur de p1 est "pointeur vers s1.a" car
                                       // s1.a et s1 sont interchangeables par pointeur
int* p2 = reinterpret_cast<int*>(&s2); // la valeur de p2 est inchangée par reinterpret_cast
                                       // et est "pointeur vers s2". 
int* p3 = reinterpret_cast<int*>(&u);  // la valeur de p3 est "pointeur vers u.a" :
                                       // u.a et u sont interchangeables par pointeur
double* p4 = reinterpret_cast<double*>(p3); // la valeur de p4 est "pointeur vers u.b" : u.a et
                                            // u.b sont interchangeables par pointeur car
                                            // les deux sont interchangeables par pointeur avec u
int* p5 = reinterpret_cast<int*>(&arr); // la valeur de p5 est inchangée par reinterpret_cast
                                        // et est "pointeur vers arr"

Effectuer un accès à un membre de classe qui désigne un membre de données non statique ou une fonction membre non statique sur une glvalue qui ne désigne pas réellement un objet du type approprié - tel que celui obtenu via un reinterpret_cast - entraîne un comportement indéfini :

struct S { int x; };
struct T { int x; int f(); };
struct S1 : S {};    // disposition standard
struct ST : S, T {}; // pas de disposition standard
S s = {};
auto p = reinterpret_cast<T*>(&s); // la valeur de p est "pointeur vers s"
auto i = p->x; // l'expression d'accès au membre de classe est un comportement indéfini ;
               // s n'est pas un objet T
p->x = 1; // comportement indéfini
p->f();   // comportement indéfini
S1 s1 = {};
auto p1 = reinterpret_cast<S*>(&s1); // la valeur de p1 est "pointeur vers le sous-objet S de s1"
auto i = p1->x; // OK
p1->x = 1;      // OK
ST st = {};
auto p2 = reinterpret_cast<S*>(&st); // la valeur de p2 est "pointeur vers st"
auto i = p2->x; // comportement indéfini
p2->x = 1;      // comportement indéfini

De nombreux compilateurs émettent des avertissements de "strict aliasing" dans de tels cas, même si techniquement ces constructions enfreignent autre chose que le paragraphe communément appelé la "strict aliasing rule".

Le but des règles de l'aliasing strict et des règles associées est de permettre l'analyse d'alias basée sur les types, qui serait anéantie si un programme pouvait valablement créer une situation où deux pointeurs vers des types non liés (par exemple, un int * et un float * ) pourraient exister simultanément et que tous deux puissent être utilisés pour charger ou stocker la même mémoire (voir cet email sur le réflecteur SG12 ). Par conséquent, toute technique semblant capable de créer une telle situation invoque nécessairement un comportement indéfini.

Lorsqu'il est nécessaire d'interpréter les octets d'un objet comme une valeur d'un type différent, std::memcpy ou std::bit_cast (depuis C++20) peut être utilisé :

double d = 0.1;
std::int64_t n;
static_assert(sizeof n == sizeof d);
// n = *reinterpret_cast<std::int64_t*>(&d); // Comportement indéfini
std::memcpy(&n, &d, sizeof d);               // OK
n = std::bit_cast<std::int64_t>(d);          // également OK

En C, la copie et l'assignation d'agrégats accèdent à l'objet agrégé dans son ensemble. Mais en C++, de telles actions sont toujours effectuées via un appel de fonction membre, qui accède aux sous-objets individuels plutôt qu'à l'objet entier (ou, dans le cas des unions, copie la représentation de l'objet, c'est-à-dire via unsigned char ).

Mots-clés

reinterpret_cast

Exemple

#include <cassert>
#include <cstdint>
#include <iostream>
int f() { return 42; }
int main()
{
    int i = 7;
    // pointeur vers entier et retour
    std::uintptr_t v1 = reinterpret_cast<std::uintptr_t>(&i); // static_cast est une erreur
    std::cout << "The value of &i is " << std::showbase << std::hex << v1 << '\n';
    int* p1 = reinterpret_cast<int*>(v1);
    assert(p1 == &i);
    // pointeur de fonction vers un autre et retour
    void(*fp1)() = reinterpret_cast<void(*)()>(f);
    // fp1(); comportement indéfini
    int(*fp2)() = reinterpret_cast<int(*)()>(fp1);
    std::cout << std::dec << fp2() << '\n'; // sûr
    // aliasing de type via pointeur
    char* p2 = reinterpret_cast<char*>(&i);
    std::cout << (p2[0] == '\x7' ? "This system is little-endian\n"
                                 : "This system is big-endian\n");
    // aliasing de type via référence
    reinterpret_cast<unsigned int&>(i) = 42;
    std::cout << i << '\n';
    [[maybe_unused]] const int &const_iref = i;
    // int &iref = reinterpret_cast<int&>(
    //     const_iref); // erreur de compilation - impossible de supprimer const
    // Doit utiliser const_cast à la place : int &iref = const_cast<int&>(const_iref);
}

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

Rapports de défauts

Les rapports de défauts modifiant le comportement suivants ont été appliqués rétroactivement aux normes C++ précédemment publiées.

Références

Voir aussi