Dans son récent discours «Type punning en C ++ moderne», Timur Doumler a déclaré que std::bit_castcela ne peut pas être utilisé pour convertir un bit floaten un unsigned char[4]car les tableaux de style C ne peuvent pas être renvoyés d'une fonction. Nous devons utiliser std::memcpyou attendre C ++ 23 (ou version ultérieure) lorsque quelque chose comme reinterpret_cast<unsigned char*>(&f)[i]cela deviendra bien défini.

En C ++ 20, pouvons-nous utiliser un std::arrayavec std::bit_cast,

float f = /* some value */;
auto bits = std::bit_cast<std::array<unsigned char, sizeof(float)>>(f);

au lieu d'un tableau de style C pour obtenir des octets d'un float?

Oui, cela fonctionne sur tous les grands compilateurs, et pour autant que je sache en regardant la norme, il est portable et garanti de fonctionner.

Tout d'abord, il std::array<unsigned char, sizeof(float)>est garanti qu'il s'agit d'un agrégat ( https://eel.is/c++draft/array#overview-2 ). Il s'ensuit qu'il contient exactement un sizeof(float)certain nombre de chars à l'intérieur (généralement sous la forme a char[], bien que la norme afaics n'impose pas cette implémentation particulière - mais il dit que les éléments doivent être contigus) et ne peut pas avoir de membres non statiques supplémentaires.

Il est donc trivialement copiable, et sa taille correspond également à celle de float.

Ces deux propriétés vous permettent de les bit_castséparer.

La réponse acceptée est incorrecte car elle ne prend pas en compte les problèmes d'alignement et de remplissage.

Par [tableau] / 1-3 :

L'en-tête <array>définit un modèle de classe pour stocker des séquences d'objets de taille fixe. Un tableau est un conteneur contigu. Une instance de array<T, N>stocke des Néléments de type T, c'est size() == Ndonc un invariant.

Un tableau est un agrégat qui peut être initialisé par liste avec un maximum d' N éléments dont les types sont convertibles en T.

Un tableau répond à toutes les exigences d'un conteneur et d'un conteneur réversible ( [container.requirements]), sauf qu'un objet tableau construit par défaut n'est pas vide et que l'échange n'a pas une complexité constante. Un tableau répond à certaines des exigences d'un conteneur de séquence. Les descriptions sont fournies ici uniquement pour les opérations sur tableau qui ne sont pas décrites dans l'un de ces tableaux et pour les opérations où il existe des informations sémantiques supplémentaires.

La norme n'exige pas réellement std::arrayd'avoir exactement un membre de données publiques de type T[N], donc en théorie il est possible que sizeof(To) != sizeof(From)ou is_­trivially_­copyable_­v<To>.

Je serai cependant surpris si cela ne fonctionne pas dans la pratique.

Oui.

Selon l' article qui décrit le comportement de std::bit_cast, et sa mise en œuvre proposée dans la mesure où les deux types ont la même taille et sont copiables, la distribution devrait réussir.

Une implémentation simplifiée de std::bit_castdevrait ressembler à:

template <class Dest, class Source>
inline Dest bit_cast(Source const &source) {
    static_assert(sizeof(Dest) == sizeof(Source));
    static_assert(std::is_trivially_copyable<Dest>::value);
    static_assert(std::is_trivially_copyable<Source>::value);

    Dest dest;
    std::memcpy(&dest, &source, sizeof(dest));
    return dest;
}

Depuis un flotteur (4 octets) et un tableau de unsigned charpar size_of(float)rapport à tous ceux affirme, le sous - jacent std::memcpysera exécuté. Par conséquent, chaque élément du tableau résultant sera un octet consécutif du flottant.

Afin de prouver ce comportement, j'ai écrit un petit exemple dans l'explorateur du compilateur que vous pouvez essayer ici: https://godbolt.org/z/4G21zS . Le flottant 5.0 est correctement stocké sous la forme d'un tableau d'octets ( Ox40a00000) qui correspond à la représentation hexadécimale de ce nombre flottant dans Big Endian .