Je suis tombé sur le code suivant et on m'a dit que cela signifie que col_8888_red code> est "Endian Indépendant". Pourquoi? Qu'est-ce qui rend cette endian indépendante?
(J'ai demandé au codeur d'origine mais ils ne me répondent pas ... Heck peut-être ils em> ne savent pas non plus.) union _colours {
uint8 c[3][4];
uint32 alignment;
};
static const union _colours col_8888 = {
{ /* B G R A in memory */
{ 0x00, 0x00, 0xFF, 0xFF, }, /* red */
{ 0x00, 0xFF, 0x00, 0xFF, }, /* green */
{ 0xFF, 0x00, 0x00, 0xFF, }, /* blue */
}
};
#define COL_8888_RED *((uint32 *)&col_8888.c[0])
3 Réponses :
Ce code n'est pas "indépendant de l'endian" dans un sens que les plates-formes avec différentes endansions vous donneront différentes valeurs via Une question différente est que mais néanmoins, dire que la valeur de col_8888_red code>. En d'autres termes, dans la compréhension traditionnelle de la dépendance de l'endian, ce code est aussi dépendant de l'endian que jamais. P>
col_8888_red code> est censé être utilisé. Peut-être qu'elle est destinée à être transmise à une API, qui est en elle-même dépendante de l'Endian, de la même manière au point que la dépendance de l'API annule la dépendance endociale de col_8888_red code>. Dans ce cas, tout fonctionnera "comme prévu", c'est-à-dire endian-indépendamment. (Par exemple, si l'API reçoit la valeur de couleur sous la forme uint32 CODE>, puis le sépare dans les composants ARGB en utilisant le même syndicat, il obtiendra les valeurs ARGB originales correctes quelle que soit l'endansité.) P >
col_8888_red code> est en soi indépendante est totalement incorrecte. P>
@Andrey, serait un terme meilleur être "endian agnostique" alors?
@Beeband, alors nous voyons la question "Pourquoi ce code est-il endian agnostique". Le même degré de détermination de celui-ci ira à tout autre terme utilisé.
@Andrey, col_8888_red code> va être écrit directement sur un élément dans un tableau de uint32 code>.
@Beeband: "écrit directement à un élément dans un tableau". Super. Et quoi ensuite?
@Andreyt, la matrice de uint32 code> appartient à un objet "Canvas" qui est alors rendu à l'écran via des fonctions non visibles pour moi, elles sont enveloppées dans les bibliothèques que j'utilise.
@Beeband: Dans ce cas, comme je l'ai dit dans ma réponse, la dépendance de l'Endian- [in] du code résultant dépendra de ce que ces fonctions font en interne avec ce tableau. Et cette conclusion de dépendance endian- [in] s'appliquera à la combinaison i> de ce que vous avez posté et de ce que vous avez fait dans ces fonctions. Mais hors de contexte, seul, seul ce que vous avez affiché est explicitement et évidemment endedian.
Je suppose que col_8888_red, comme une macro, sera toujours un UINT32, qui, tant que la macro col_8888_red est toujours utilisée, le tableau d'octets source {0x00,0x00,0xff, 0xFF} va toujours traduire en ce que le programmateur veut dire comme rouge.
La définition signifie que vous pouvez écrire le même code source sur un grand Endian, ou un petit Endian, machine et passer d'un tableau discret à une couleur logique. P>
Modifier: pourquoi alors, pas utiliser une énumération, ou une constante comme "1"? P>
Probablement, le développeur d'API d'origine souhaitait pouvoir pointer vers un autre emplacement de {0x00,0x00,0xff, 0xFF } En mémoire, de sorte que le code comme ce qui suit pourrait être écrit: p>
FWIW, casting comme cela tombe une faute de règles strictes-aliasing, qui peuvent vraiment causer des problèmes, en particulier avec l'optimisation allumée.
Les tableaux d'octets sont de l'endansité indépendante sur presque toutes les architectures. En vous attribuant une matrice d'octet, le programmeur assure un contenu cohérent pour les données. Les octets peuvent également être consultés individuellement sur n'importe quelle architecture. Si le codeur venait de faire une matrice de 3 mots, l'endianité de la machine jouerait un rôle dans la détermination de la disposition exacte des bits. P>
Ce qui peut être indépendant de Endian n'est pas sûr, considérant que certains matériels différents peuvent choisir ArgB, BGRA, RGBA, ainsi de suite, etc.
@ Dash-Tom-Bang, en effet, d'autres types d'affichages nécessiteront de rouge, de vert et de bleu à définir dans des commandes d'octets différents. Et dans ce cas, le
col_8888 code> Union définit le rouge, le vert et le bleu pour un type d'affichage spécifique et définit donc un ordre d'octet spécifique - son être utilisé seulement i> écrire à cette Type d'affichage. Les autres types d'affichage nécessiteront différentes définitions de rouge, de vert et de bleu.