Je veux créer un syndicat dans lequel le plus grand membre est un entier 32 bits. C'est ce qui sera principalement écrit à. Ensuite, il y a quatre variables 8 bits, probablement des types de caractères qui se réfèrent chacun à une section différente du type d'entier 32 bits comme: mais je ne sais pas comment faire cela en C ++ . p> p>
4 Réponses :
Ceci peut fonctionner:
union { int32 myint; char chars[4]; };
Bien que mieux que la réponse acceptée, char code> est problématique, car il n'est pas défini comme un octet. En outre, il peut être signé ou non signé.
Vous pouvez utiliser ceci: ou avec voir uint8_t code>: p>
: 8 code> est superflu
@Captainobvlieux - Euh .. Oui bien sûr - pensait à des champs de bits.
Le nom n'est pas facultatif si c'est-il?
@Redorav j'ai supprimé ce commentaire, merci. (Je ne sais pas pourquoi je l'ai ajouté après).
union intBytes { int32 myInt; struct { char char1; char char2; char char3; char char4; }; char charArray[4]; }; intBytes dummy; Above you see that the struct wrapping char1-char4 is not assigned a name. This is called an anonymous struct. The members of an annonymous struct are directly accessible inside the scope sourrounding the struct.Without the struct char1 - char4 would overlap inside the union and all would refer to the first byte of myInt. The annonymous struct ensures that char1 - char get layed out sequentially.C has anonymous structs and unions. C++ (pre C++11) does NOT allow anonymous structs, only anonymous unions are defined. However, most C++ compilers (llvm, gcc) allow anonymous struct/unions.Anonymous structs were added to C++ in C++11.This allows you to access dummy.char4 while usually you would have to type dummy.nameOfCharStruct.char4. Since this is not standard conformant c++ (I believe it was changed in a post C++03 Standatd), you might be better of adding the name of the struct or using the array approach.
Anonyme struct code> s et
Union code> S fait partie de la norme C. Pas sûr si c ++ leur permet également.
@Oolaf: Je suppose que "C et la plupart des compilateurs C ++" est de subtil, mais certaines recherches montrent que c ++ n'autorise pas les structures anonymes tandis que les syndicats anonymes sont ok. Voici une référence (je ne suis pas d'accord avec tous les points, cependant) Stackoverflow.com/a/12785369/258418
Je m'en fiche de C ++. Pour C, j'ai fourni une référence claire. Mais je ferais attention avec "la plupart des compilateurs C". Il y a encore de nombreux compilateurs de C90 et non non standard, tels que MSVC. Mais tout compilateur C conformité standard doit B> les soutenir. La norme répertorie les deux, anonymous struct code> s et
union code> S comme une nouvelle fonctionnalité, il est donc probable que C99 ne supporte aucune (la réponse liée semble être erronée ici; Notez également sa Date). GCC les a soutenus plus longtemps comme une extension, cependant.
@Oolaf: J'espère que la réponse clarifiée supprime toute confusion
Je n'ai pas compris si vous vouliez une intergère de 32bits et 4 variables 8bits ou une scission de 32bits intermédiaire dans 4 variables 8bits, mais de toute façon, vous devriez essayer quelque chose comme ceci:
union yourUnion { int32 yourInt; struct { int32 var1 : 8; int32 var2 : 8; int32 var3 : 8; int32 var4 : 8; } yourSplitInterger; };
Oui, j'allais la diviser. Cela suffira.
Il n'y a aucune garantie que les fitfields seront stockés dans un seul int32 code>. Aussi chaque champ est signé.
Selon CPPreference , les dépôts de bits sont généralement emballés ensemble, donc non, en effet, Il n'y a aucune garantie qu'ils seront stockés dans un seul int32 code> mais je pense que c'est la meilleure pratique de ce que veut faire. En outre, je ne suis pas sûr que le fait que les champs soient signés compte vraiment en considérant que OP n'écrirea probablement
char code> dans ces fichiers bits.
1) Veuillez utiliser @name code> pour adresser un commentaire. Sinon, il va probablement inaperçu (comme le vôtre l'a fait) 2) "Habituellement" est une base assez faible. 3)
CPPreference code> n'est pas faisant autorité. Il existe une norme pour, C et C ++. Beaucoup mieux. 3) Non, ce n'est pas le cas. Parce que les champs simples seront signés maintenant, ce qui n'est probablement pas ce qu'il veut. 4) Pourquoi ne pas simplement utiliser un tableau de
uint8_t code>. Qui est garanti d'avoir aucun rembourrage. 5) Toutes ces approches sont encore dépendantes de la mise en œuvre, car elles ne respectent pas l'endianesse.
Est-ce pour C ++ ou C?
Pourquoi
Char code>? Les fitfields sont déjà basés sur
int code>.
Ce que j'ai écrit n'est pas correct c ++. Pourriez-vous élaborer ce que vous entendez par champ de bit? Essayez-vous de dire que si j'utilise Int pour Char1 à Char4, le syndicat ci-dessus est syntaxiquement correct?
Si je me souviens bien, il est illégal de céder à C ++ d'attribuer à un membre d'un syndicat et de lire un autre. Qu'est-ce que vous essayez exactement d'atteindre et écrivez-vous du code C ou C ++? Les règles pour les syndicats sont différentes entre les deux langues
Mikember, ma question était liée à C ++. Dans ma compréhension, les règles devraient être les mêmes entre les deux langues mais que je ne suis pas un expert, j'accepte ce que vous dites. Quoi qu'il en soit, des réponses données ci-dessous, j'ai trouvé ma solution. Merci.
@ Quantum231: de CPPrefreence.com :
... il est indéfini Comportement à lire du membre de l'Union qui n'a pas été récemment écrit. De nombreux compilateurs mettent en œuvre, en tant qu'extension linguistique non standard, la capacité de lire des membres inactifs d'une union. Code> En particulier Visual Studio ne fait aucune réclamation, qui lisait d'un membre qui n'était pas le dernier que vous avez attribué est légal (je ne suis pas sûr, quelle est la situation dans GCC ou Scrang). Les règles relatives aux syndicats ne sont définitivement pas les mêmes pour (standard) C et C ++.
Mon programme fonctionne et donne le résultat attendu
1) Utilisez des types standard au lieu de noms de homebrew pour les types de largeur fixe. C fournit
intn_t code> dans
stdint.h code> pour cette raison. 2) En général, il est préférable d'utiliser un non signé pour de telles applications. 3) Si tel est (DE) Serialise, le
int32 code>, vous pouvez utiliser des opérations Maj / Mask. Un bon compilateur peut détecter ces modèles et utiliser des accès aux octets sur votre plate-forme. De cette façon, vous omettez le magasin supplémentaire et vous n'avez pas à vous soucier des détails de la mise en œuvre.