Comment réserver mémoire pour des données de 80bits

Bonjour à tous,
dans un struct déjà conçu pour une taille fixée:

Code:

---

1 2 3 4 5

struct TOTO1 { short int Data[100]; byte Reserve[15]; }

---

Sur la taille total de Struct, j'ai 225 bytes.
Maintenant, je voudrais ajouter un tableau de 80bits en bool:

Code:

---

1 2 3 4 5 6

struct TOTO1 { short int Data[100]; bool Test[80]; // pour moi, Test doit occuper 10 bytes byte Reserve[5]; }

---

Au final, la taille de TOT2 est bien > celle de TOTO1

Ce que je veux est de garder la même taille TOTO1 et TOTO2.

Merci d'avance pour m'aider de trouver une solution.
Xavier

C'est peut-être de bitset dont tu as besoin, utilisable comme ceci :

Code:

---

1 2 3 4 5

struct Toto { short int Data[100]; std::bitset<80> Test; byte Reserve[5]; };

---

Est-ce que le standard garantit que le contenu du bitset est dans l'objet lui-même, et non dans un tableau alloué par new dont l'objet contiendrait un pointeur?
Si oui, OK, sinon, on se retrouve à reposer sur un détail d'implémentation.

Ne faudrait-il pas plutôt jouer avec les pragma pack ?

Ça ne changera pas la taille d'un bool.
Si tu veux intercaler un champ de 80 bits entre deux autres champs, le plus simple est un tableau de 10 char (ou (80+CHAR_BIT-1) / CHAR_BIT char si on veut supporter des architectures ésotériques) plus un #pragma pack(1).

Salut

Moi aussi j'avais pensé à l'alignement au début, mais la réponse de cob est correcte. Le code parle:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

#include <bitset> #include <iostream>   namespace notalign { struct toto1 { short int Data[100]; char Reserve[15]; };   struct toto2 { short int data[100]; bool test[80]; // pour moi, test doit occuper 10 bytes char reserve[5]; };   struct toto3 { short int D; std::bitset<80> Test; char Reserve[5]; }; }   namespace align { #pragma pack(1) struct toto1 { short int Data[100]; char Reserve[15]; };   #pragma pack(1) struct toto2 { short int data[100]; bool test[80]; // pour moi, test doit occuper 10 bytes char reserve[5]; };   #pragma pack(1) struct toto3 { short int D; std::bitset<80> Test; char Reserve[5]; }; }   int main() { std::cout << sizeof(notalign::toto1) << "\n" << sizeof(notalign::toto2) << "\n" << sizeof(notalign::toto3) << "\n" << sizeof(align::toto1) << "\n" << sizeof(align::toto2) << "\n" << sizeof(align::toto3) << "\n" << std::endl; return 1; }

---

Affiche:

Code:

---

1 2 3 4 5 6

216 286 32 215 285 23

---

La doc précise que std::bitset<N> est essentiellement un std::array<bool,N>, avec un rangement plus optimal (déjà utilisé par std::vector<bool>) et quelques constructeurs/méthodes purement utilitaires.

Le fait que le constructeur de bitset soit noexcept impose qu'il ne fasse pas d'allocation dynamique.

si bitset<> ne contenait que les 80 bits, la taille de align::toto3 devrait être 17 octets, pas 23. Il y a donc plus, ou un alignement forcé.

Merci de vos réactions.
Ce que je veux est d'insérer un tableau de 80 variables booléens dans un struct existant, bien sure, la taille de struct est limitée et il y a un trou de dizaine d'octets. Je ne peux pas trop changé le struct pour la compatibilité avec l'ancienne version de mon programme.
Xavier

Tu peux p-e mais en entrant à la main les 80 variables

Code:

---

1 2 3

bool b1:1; bool b2:1; ...

---

En tous cas pas avec un tableau ou assimilé. http://social.msdn.microsoft.com/For...orum=vcgeneral

Citation:

---

An array must be able to decay into a pointer. However, there is no such thing (in C/C++) as a pointer to a bit. For instance the following code would fail horribly without a major overhaul to the language type system:

bool *actPtr = ActionStruct.action;

actPtr++;

---

L'explication est qu'un tableau doit être vu comme un pointeur, et un pointeur de bit n'existe pas.

Salut,

En fait, la question que personne n'a posée est : est-ce que ta structure doit obligatoirement utiliser un espace mémoire correspondant à la somme de ses champs :question:

A priori, je dirais que non! Je m'explique:

Le seul intérêt qu'il pourrait y avoir au fait que la taille de ta structure soit effectivement égale à la somme des tailles de ses champs, ce serait de pouvoir coper la mémoire d'une seule traite, sous une forme proche de

Code:

---

1 2 3 4

unsigned char * data = new char[sizeof(laStructrure)* nombreElements]; /* récupération des données d'une manière ou d'une autre (lecture dans un fichier binaire?) */ laStructure * tab= new laStructure[nombreElements]; memcpy(tab, data, sizeof(laStructure)*nombreElement);

---

Autrement dit, d'avoir un type réellement POD, dans l'esprit et dans la lettre.

Et encore, on pourrait parfaitement appliquer cette méthode à une structure qui manipule un bitset car, comme l'a fait remarquer Loyc, le constructeur est noexcept, ce qui fait que la représentation interne du bitstet est tout, sauf un tableau dynamique.

Du coup, on peut se demander s'il est vraiment "bloquant" d'avoir une structure qui soit représentée en mémoire sous la forme de

• 200 bytes pour data (je considère que sizeof(short) == 2 ;))
• 8 bytes pour les données internes supplémentaires du bitset
• 10 byte pour les booléens de test et
• 5 byte pour reserve

au lieu d'une structure qui serait représentée sous la forme de

• 200 bytes pour data (je considère que sizeof(short) == 2 ;))
• 10 byte pour les booléens de test et
• 5 byte pour reserve

Après tout, on parle de 8 malheureux bytes! (et encore, ce sont les valeurs que j'obtiens sur mon linux 64 bits, on parlerait d'une différence de 4 bytes sur une architecture 32 bits, soit 1.8 % de pertes), ce qui correspond à une "perte" de quoi :question: 3.7 % d'espace mémoire :question:

Les cas où il est réellement indispensable de limiter la taille d'une structure de la sorte sont, finalement, particulièrement rares parce que, même si std::bitset est composé d'un membre de la taille d'un size_t en plus des données utiles, il faut déjà avoir beaucoup d'éléments à représenter en mémoire, ou être particulièrement limité en mémoire, pour que cette différence de taille en vienne à poser des problèmes.

Je ne dis pas que la perte occasionnée par le fait qu'il y ait 3.7% d'espace mémoire utilisé "inutilement" du point de vue des données que tu dois manipulé est sans importance, loin de là.

Je dis juste que, si tu es vraiment limite par rapport à la mémoire dont tu disposes, ce ne sont pas ces 4% (même pas) qui feront une très grosse différence :aie:

Merci koala01,
je ne comprends pas très bien la dernière solution.
Selon les testes "jblecanard", il y a une différence importante: tailles 216 et 286 pour structs Toto1 et Toto2.

Dans mon cas, il s'agit d'une réutilisation des espaces dispos dans un struct (statique) pour créer un tableau de 80 bits. Il me faut vraiment un tableau afin d'automatiser son utilisation.
Je peux tolérer 15 octets (au lieu de 70 octets dans le struct Toto2), je ne sais pas comment le faire pour un struct statique (pas d'allocation de mémoire dynamique).
Merci d'avance
Xavier

Personnellement, je me suis basé sur deux structures différentes proches de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

struct S{ short data[100]; char reserve[5]; }; struct S1{ short data[100]; unsigned char test[10]; char reserve[5]; }; struct S2{ short data[100]; std::bitset<80> test; char reserve[5]; }; int main(){ std::cout<<sizeof(short)<<std::endl; std::cout<<sizeof(S)<<std::endl; std::cout<< sizeof(S1)<<std::endl; std::cout<< sizeof(S2)<<std::endl; return 0; }

---

Pour S1, je me suis basé sur le fait couremment admis qu'un byte (ou un unsigned char, vu que c'est pareil) est généralement codé sur 8bits, bien que cela puisse varier sur certaines architectures.

Quand je compile ce code en mode 64bits sous linux, j'obtiens l'affichage suivant :

Code:

---

1 2 3 4 5 6 7

2 206 216 224 0x7fffb2568e10 0x7fffb2568ed8 0x7fffb2568ee0 0x7fffb2568fa8 0x7fffb2568fb2 0x7fffb2568fc0 0x7fffb2569088 0x7fffb2569098

---

Et, lorsque je le compile en mode 32bits, j'obtiens l'affichage

Code:

---

1 2 3 4 5 6 7

2 206 216 220 0xffd7bd2a 0xffd7bdf2 0xffd7bdf8 0xffd7bec0 0xffd7beca 0xffd7bed0 0xffd7bf98 0xffd7bfa4

---

Ces deux sorties sont pleines d'enseignements :D

La première chose, c'est qu'il y a visiblement déjà un alignement qui est effectué au niveau de S, aussi bien en mode 32 bits qu'en mode 64bits. En effet, le 2 nous indique que la taille d'un short est de 2bytes. Mais, dans mon système de calcul, 2*100 + 5 donne 205 et non 206.

Comme il n'y a qu'un byte de différence entre la taille "théorique" de S (205) et la taille que la sortie nous présente (206), on peut être quasiment certain que l'alignement se fait au niveau du champs reserve. Chose dont nous pourrions nous assurer en modifiant la structure S sous la forme de

Code:

---

1 2 3 4

struct S{ short data[100]; char reserve[6]; };

---

qui nous permettrait de nous rendre compte que sizeof(S) est toujours bel et bien égal à 206.

La ligne de sortie 0x7fffb2568e10 0x7fffb2568ed8(respectivement 0xffd7bd2a 0xffd7bdf2 en mode 32bits) nous le confirme d'ailleurs, car, si on soustrait 0x7fffb2568e10 de 0x7fffb2568ed8, on obtient bel et bien 200, qui est la taille occupée en mémoire par 100 short ;)

La ligne représentant les adresses des champs de S1, à savoir 0x7fffb2568ee0 0x7fffb2568fa8 0x7fffb2568fb2(respectivement 0xffd7bdf8 0xffd7bec0 0xffd7beca) nous indique qu'il n'y a apparemment pas d'alignement nécessaire lorsque l'on décide de représenter nos 80bytes sous la forme d'un tableau de 10 unsigned char car si l'on soustrait 0x7fffb2568fa8 de 0x7fffb2568fb2, on obtient bel et bien 10, ce qui correspond bien au nombre de byte auquel on peut s'attendre si on veut un espace de 80bits (du moins, pour autant que le byte fasse effectivement 8bits :D)

Enfin, la ligne représentant les adresses des champs de S2 -- je veux bien sur parler de 0x7fffb2568fc0 0x7fffb2569088 0x7fffb2569098 (respectivement 0xffd7bed0 0xffd7bf98 0xffd7bfa4 en mode 32bits) nous apprend qu'il y a un écart de 16 bytes (respectivement de 12 bytes, en mode 32 bits) entre l'adresse du champs test et celle du champs reserve.

Cet écart est tout à fait normal car std::bitset est, d'abord et avant tout une structure de donnée. Autrement dit, c'est un type "complexe" qui n'a rien à voir avec les types primitifs. Le compilateur doit donc s'assurer que, quel que soit la donnée qui suivra un élément de type std::bitset en mémoire se retrouvera à une adresse accessible.

Pour pouvoir donner cette garantie, il faut que le compilateur "réserve" un espace mémoire suffisant pour placer les données de la structure en l'étendant jusqu'à l'adresse mémoire accessible suivante.

Les architectures 32bits, classiquement, facile à accéder à des adresses mémoire qui sont multiple de 32, quand les architectures 64bits ont classiquement facile à accéder à des adresses mémoire qui sont multiple de 64. C'est la raison pour laquelle on parle si volontier d'architecture 32 et 64bits d'ailleurs :D. Si l'on se base sur le fait qu'un byte correspond à 8bits et que le byte est "indivisible" (en terme d'adresse mémoire, s'entend :D) on se rend effectivement compte que, si on commence à compter la mémoire à partir de 0, un système 32bits pourra accéder à toutes les adresses mémoire qui sont multiples de 4 (parce que 4*8 = 32) et qu'un système 64bits pourra accéder à toutes les mémoire qui sont multiples de 8 (parce que 8*8=64).

L'écart que l'on retrouve entre les 10bytes nécessaires pour représenter nos 80bits et les 16bytes (respectivement les 12 bytes en mode 32bits) qui séparent le début de test du début de reserve se justifie donc pleinement par le fait que le compilateur doit s'assurer qu'il sera possible d'accéder au premier élément de reserve au travers d'une adresse mémoire accessible ;).

On peut se rendre compte qu'il s'agit bel et bien d'un problème d'alignement (et non de la présence d'un membre comme je le pensais lors de ma première intervention) en modifiant quelque peut la structure S2, sous la forme de

Code:

---

1 2 3 4 5

struct S2{ short data[100]; std::bitset<128> test; char reserve[5]; };

---

si l'on compile en 64 bits et sous la forme de

Code:

---

1 2 3 4 5

struct S2{ short data[100]; std::bitset<96> test; char reserve[5]; };

---

car la taille affichée pour S2 sera toujours de 224 en mode 64bits et de 220 en mode 32bits ;).

Mais donc, ce qu'il est important de retenir, c'est que le cout d'utilisation d'un bitset en terme d'espace mémoire utilisé ne sera jamais que celui d'un alignement rendu obligatoire par le fait que l'on utilise un type personnalisé (fusse-t-il fourni par le langage lui-même) au lieu d'un (éventuel tableau de) type(s) primitif.

Ce cout se chiffrant à quelque pourcent maximum (on parle de maximum 8 bytes sur une structure qui en compte déjà plus de 200, en mode 64bits), il me semblerait vraiment dommage de renoncer à l'utilisation de std::bitset ;)

Merci koala01 pour ta contribution.
je ne connais pas trop C++ ben que je l'ai utilisée depuis un certain temps sous C++Builder.
J'ai testé

Code:

---

1 2 3 4 5

struct S2{ short data[100]; std::bitset<128> test; char reserve[5]; };

---

Compilation erreur: 'bitset' n'est pas un membre de std ?

Une petite lumière stp
Xavier

Un petit #include <bitset> au plus tard avant la définition de S2, peut être :question: :D

Citation:

---

Envoyé par koala01

Un petit #include <bitset>au plus tard avant la définitino de S2, peut être :question: :D

---

Merci, c'est juste ce qui manque!
Je vais intégrer cette solution dans mon appli
A+
Xavier

Attention, la solution de koala te change la taille de ta structure. J’avais cru comprendre que c’était ce que tu devais éviter (maintien de compatibilité binaire ?)

Si tu ne veux pas changer la taille de ta structure, il faut enlever le reserve (en 64 bits uniquement, en 32 il te faut peut-être un reserve <= 4 à la fin.).

Si tu es en c++11, je te conseille de rajouter quelque part un static_assert(sizeof(S1) == sizeof(S2), "Size differs") histoire d’être tranquille.

Effectivement,
j'ai joué sur"char reserve[5]": faute de frappe, j'ai initialement 500 octets comme réserve "char" à la fin dans la struct;
Merci
Xavier

Bonjour à tous,

Certains compilos offrent une option permettant d'afficher en ASCII l'organisation mémoire d'une classe/struct. Exemple avec VC++:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#include <bitset>   struct S{ short data[100]; char reserve[5]; }; struct S1{ short data[100]; unsigned char test[10]; char reserve[5]; }; struct S2{ short data[100]; std::bitset<80> test; char reserve[5]; };

---

Code:

---

cl /c main.cpp /d1reportAllClassLayout > layout.txt

---

résultat:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class S size(206): +--- 0 | data 200 | reserve | <alignment member> (size=1) +---   class S1 size(216): +--- 0 | data 200 | test 210 | reserve | <alignment member> (size=1) +---   class S2 size(224): +--- 0 | data 200 | ?$bitset@$0FA@ test 216 | reserve | <alignment member> (size=3) +---

---

Il me semble qu'il y a un équivalent avec g++ mais je le retrouve pas (-fdump-class-hierarchy ne fait pas tout à fait la même chose). Pour C++ Builder je ne sais pas.