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

**Xavier** · 30/01/2014, 09h02

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**cob59** · 30/01/2014, 09h46

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Médinoc** · 30/01/2014, 15h53

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.

**Bousk** · 30/01/2014, 15h55

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

**Médinoc** · 30/01/2014, 15h58

Ç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).

**jblecanard** · 30/01/2014, 16h20

Salut

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

**cob59** · 30/01/2014, 16h32

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.

**JolyLoic** · 30/01/2014, 17h01

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

**Médinoc** · 30/01/2014, 17h02

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é.

**Xavier** · 04/02/2014, 01h19

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

**Bousk** · 04/02/2014, 12h01

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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.

**koala01** · 04/02/2014, 17h31

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

3.7 % d'espace mémoire

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

**Xavier** · 04/02/2014, 23h05

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

**koala01** · 05/02/2014, 01h02

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

)

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

. 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

) 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Xavier** · 05/02/2014, 03h25

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**koala01** · 05/02/2014, 03h30

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

**Xavier** · 05/02/2014, 03h43

Envoyé par koala01

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

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

**white_tentacle** · 05/02/2014, 12h22

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.

**Xavier** · 06/02/2014, 12h09

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

**Aurelien.Regat-Barrel** · 06/02/2014, 19h30

Bonjour à tous,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

C++

Discussions similaires

Partager

Partager