Discussion :

[neismarspra]

Bonjour,

J'utilise Code::Blocks 10.05 avec MinGW / GNU GCC (4.4.1. mais pas sur.).
Je déclare:

Code :

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

1
2
3
4
5
6
7
8
9
struct In
{
    unsigned int a;
    double b;
    double c;
    double d;
    double e;
    double f;
};

Pour lire "un tableau" de ces valeurs, qu'ils y ont étés laisser pas un autre processus.
J'ai verifié dans "la ram" et je vois bien que 'a' est codé sur 4 Octets, et les autres variables sur 8 Octets, et que les différents bloc de données se suivent directement, comme cela:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
|----------------------------------------------------------------------|
|----------------"1er struct"-------------------------------------------|
| 4O |bloc de 8 octets|bloc de 8 octets|bloc de 8 octets|bloc de 8 octets|
-----------------------------------------------------------------------|
-----------------|------------"2nd struct"------------------------------|
|bloc de 8 octets| 4O |bloc de 8 octets|bloc de 8 octets|bloc de 8 octets|
-----------------------------------------------------------------------|
---------------------------------|-----------"3eme struct"-------------|
|bloc de 8 octets|bloc de 8 octets| 4O |bloc de 8 octets|...........
----------------------------------------------------------

mais mais quand j'appelle

Code :

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

sizeof(struct In)

j'obtiens 48 à la place de 44.

Je me dit qu'il me manque un élément assez important sur le fonctionnement et l'utilisation de struct....

[bretus]

Bonjour,

C'est normal, ça s'appelle l'alignement des structures.

http://fr.wikipedia.org/wiki/Alignement_en_m%C3%A9moire

Le compilo bourre ta structure comme suite :

Code :

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

1
2
3
4
5
6
7
8
9
10
struct In
{
    unsigned int a;
    char _bourrage[4];
    double b; //aligne sur 8
    double c;
    double d;
    double e;
    double f;
};

La taille est donc correcte pour chaque membre, mais la taille totale est augmenté d'un membre "fictif".


Contourner ce mécanisme qui permet d'optimiser l'accès à la RAM en fonction des contraintes du processeur est une mauvaise idée.

Si l'autre processus modifie l'alignement (ce qui m'étonnerait), il faut voir du coté de "pack" :
http://gcc.gnu.org/onlinedocs/gcc/St...g-Pragmas.html

[neismarspra]

Je vais voire ca tous de suite...

en faite ils faut que j'appelle une fonction qui "recopie" tous le tableau vers une autre variable, dans le premier processus, pour que je puisse travailler dessus corectement avec mon code. Le problèm c'est que je n'ai pas acces au code source, et le debuggage "normale" n'est pas disponible, car ils est bloqué..
Et je suis en manque mflops, donc je préfère tout gérer depuis mon code..

"Si l'autre processus modifie l'alignement (ce qui m'étonnerait)":
a mon humble avis, ce n'est pas du c++, encore que.. mais des que je vue les premier dump je me suis dit que c'est fait exprès pour economisé la ram. Car a l'origine il n'est pas question de calcule intensif mais de stockage de beaucoup de donnée.

[neismarspra]

Super ca marche
Merci.