Alignement sur un octet de la structure en conflit avec l’exigence d’alignement de l’architecture?

J’ai précédemment posté une question ici sur l’access aligné lors de la diffusion du pointeur. En résumé, il est préférable de ne pas utiliser l’access non aligné pour être entièrement portable, car certaines architectures peuvent générer une exception ou les performances peuvent devenir assez lentes par rapport à un access aligné.

Cependant, dans certains cas , je souhaite utiliser un alignement sur un octet, par exemple, lors du transfert de données réseau, je ne souhaite pas append de rembourrage supplémentaire dans la structure. Donc, habituellement, ce qui est fait ici est:

#pragma pack (push, 1) struct tTelegram { u8 cmd; u8 index; u16 addr1_16; u16 addr2_16; u8 length_low; u8 data[1]; }; #pragma pack (pop) 

Alors vous connaissez peut-être déjà ma question: si j’applique un alignement d’un octet sur ma structure, cela signifie-t-il qu’il ne peut pas être totalement portable, car les membres de la structure ne sont pas alignés? Et si je veux à la fois l’absence de rembourrage et la portabilité?

Merci!

Premièrement, les access mémoire mal alignés font référence à des données uniques qui couvrent plusieurs mots en mémoire. Par exemple: sur un système 32 bits, un entier 32 bits à l’adresse 0, 4, 8, etc. est aligné, mais à 1, 2, 3, 5, 6, 7, 9, etc., serait mal aligné.

Deuxièmement, les données mal alignées ne “lèvent pas une exception” au sens C ++, mais peuvent générer une interruption / interruption / exception au niveau de la CPU – par exemple SIGBUS sous UNIX, où vous définiriez généralement un gestionnaire de signal pour réagir à cela, Toutefois, si vous devez parsingr des données mal alignées de manière portable, vous ne ferez pas attention aux signaux: vous coderiez manuellement les étapes pour emballer et décompresser les données couvrant les limites de mots.

Dans votre structure tTelegram , les données ne sont pas “mal alignées”, mais le processus de décalage de bits et de masquage des données lorsqu’elles sont compressées / décompressées à partir d’un registre est toujours plus lent (nécessitant plus d’instructions de code machine) que d’utiliser des données occupant un mot indépendant. .

En ce qui concerne la portabilité – tous les compilateurs non-jouets auront la possibilité de compresser comme vous l’avez décrit, mais le pragma exact variera, la disposition des octets dans les valeurs sur plusieurs octets peut toujours être big-endian ou little-endian (ou étrange), et si certains processeurs autorisent certains access aux données mal alignés (x86, par exemple), d’autres non (Ultrasparc, par exemple).

Lors du transfert de données entre différents ordinateurs, vous souhaitez toujours formater vos données. Notez qu’un format de données n’a pas besoin d’être lisible, mais peut très bien être binary. Un format binary inclurait la position exacte de chaque élément de données, son type, pour les données multi-octets, l’ordre d’affichage des octets, la taille ou un moyen de déterminer la taille, etc. N’utilisez pas de format défini plus tard.

Autrement dit, même si j’ai vu les approches telles que vous les décrivez, je ne pense pas qu’elles soient normales et qu’elles ne le sont certainement pas quand il s’agit de définir un format entre différentes entités (des entresockets sûrement, probablement aussi entre différents départements et / ou groupes). ). Aux endroits où j’ai travaillé pour recevoir et envoyer des données, le format exact était certainement défini. Si le format défini peut être mis en correspondance avec la structure de données dans une struct il est certainement également utilisé pour décoder les données, mais il est connu pour ne pas être portable et le code censé être portable ne tente pas d’utiliser de telles installations. Au lieu de cela, il utilise quelque chose qui lit / écrit les enregistrements pertinents et décode / code les différents de manière appropriée. Souvent, le code de décodage / codage est généré à partir d’une sorte de méta format décrivant la présentation exacte des données.