Discussion :

[- Robby -]

Bonjour à tous.

Existe-t-il un équivalent C à "packed record" (Pascal) ?

"packed record" ... ce n'est pas du C bien entendu, c'est du Pascal. Il s'agit d'une directive donnée au compilateur Pascal et qui concerne les "structures". Avec "packed record" on est certain que la structure se trouve en mémoire comme elle a été déclarée ... sans allignement, sans être scindée.

En C ...
En ce qui concerne l'allignement, j'ai "# pragma (push,1)". Ceci va forcer le compilo C a considérer le byte et rien d'autres. Donc pas d'allignement.

mais ... ce "non-allignement", en théorie, n'empeche pas le compilo C de scinder la structure en parties non contigues physiquement ! Existe-t-il, en C, une directive qui permet d'être certain que ma structure se trouve physiquement en mémoire en "un seul bloc continu" ?

Merci à tous et une toute bonne journée.

[ram-0000]

Il y a les directives "#pragma pack" et "#pragma align" pour faire l'équivalent. Je ne sais pas si le compilateur est ''obligé" de se soumettre à la directive ou si de toute façon, il fait ce qu'il veut.

Juste une remarque en passant, dès que l'on a besoin de jouer avec ses directives, cela devient un peu risqué.

Dans ces cas, je préfère utiliser un tableau de unsigned char et "jouer" avec les offsets dans ce tableau (même si certaines valeurs sont sur 2 ou 4 octets)

[- Robby -]

Bien entendu que le compilateur est "obligé" de suivre les directives que tu lui donnes ... Les directives "pragma" sont mêmes prioritaires sur tous autres directives de compilation (/Zp par exemple). Si tu lui donnes la directive "#pragma pack (push,1) / #pragma pack (pop)", entre les deux tu lui interdis tout allignement au delà du byte ... donc pas d'allignement ! Un compilo, ça ne "pense" pas, et ça ne fait pas ce qu'il veut "malgré tout" ... pas de tracas. hi

"#pragma align" ne semble pas exister pour le compilo C de Microsoft ... en tout cas pas dans celui de Visual Studio 2005 ou 2008. Mais "#pragma pack (push , n) suffit pour toutes questions d'allignement.

Bon ...
Tout ceci ne m'apporte pas de réponse à ma question.
Avec "#pragma pack (push,1), je sais que tous les champs de ma structure se retrouvent physiquement tel quel en mémoire. Mais cela, dans l'absolu, n'empêche pas le compilo de "couper" physiquement ma structure "entre 2 champs".

En Pascal, "Packed Reccord" interdit cela ... mais en C ???

ps
---
Le fait ne "jouer" avec un tableau de "byte" n'enlève pas le risque que ce tableau soit découpé physiquement par le compilo. Ce découpage est transparent dans la plupart des cas ... si tu y fais référence "normalement", tu ne t'en apercevras jamais. Sauf si tu essayes de récupérer en une seule fois, 2 bytes consécutifs, dans un word.

[Neitsa]

Bonjour,

A ma connaissance, #pragma pack assure qu'il n'y aura pas de padding dans la structure (a contrario de __declspec align qui aligne la base de la structure et pad les champs pour qu'ils soient alignés).

Dans Winnt.h on trouve plusieurs structures packées de la sorte grâce à des en-têtes.

On trouve ça, par exemple, dans le fichier d'en-tête pshpack1.h

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
 
/*++
 
Copyright (c) Microsoft Corporation.  All rights reserved.
 
Module Name:
 
    pshpack1.h
 
Abstract:
 
    This file turns 1 byte packing of structures on.  (That is, it disables
    automatic alignment of structure fields.)  An include file is needed
    because various compilers do this in different ways.  For Microsoft
    compatible compilers, this files uses the push option to the pack pragma
    so that the poppack.h include file can restore the previous packing
    reliably.
 
    The file poppack.h is the complement to this file.
 
--*/

A partir du moment où la structure est packée sur un octet, il ne peut pas y avoir de padding entre deux champs.

[Emmanuel Delahaye]

Existe-t-il un équivalent C à "packed record" (Pascal) ?

"packed record" ... ce n'est pas du C bien entendu, c'est du Pascal. Il s'agit d'une directive donnée au compilateur Pascal et qui concerne les "structures". Avec "packed record" on est certain que la structure se trouve en mémoire comme elle a été déclarée ...

Pas de manière portable, parce que le C est universel et que sur certaines plateformes, c'est tout simplement impossible.

Par contre, ça peut exister sur certains compilateurs. A manier avec précaution en sachant que ce code n'est pas portable.

sans allignement, sans être scindée.

En C ...
En ce qui concerne l'allignement, j'ai "# pragma (push,1)". Ceci va forcer le compilo C a considérer le byte et rien d'autres. Donc pas d'allignement.

mais ... ce "non-allignement", en théorie, n'empeche pas le compilo C de scinder la structure en parties non contigues physiquement ! Existe-t-il, en C, une directive qui permet d'être certain que ma structure se trouve physiquement en mémoire en "un seul bloc continu" ?

Attention, l'alignement n'a rien à voir avec la contigüité qui, elle est toujours garantie tant que la structure est linéaire (pas de pointeurs).

L'alignement concerne des contraintes physiques liées à l'architecture. Par exemple sur Freescale PowerPC, on ne sait pas accéder à un objet de 16-bit à une adresse impaire. Ca signifie que

Code :

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

1
2
3
4
5
6
7
 
/* taille valides sur Power PC ou x86 */
struct st
{
   char x; /* 8-bit */
   short y; /* 16-bit */
};

sera obligatoirement encodé :

Code :

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

1
2
3
4
5
 
[0] x
[1] padding
[2] MSB y (adresse paire)
[3] LSB y

Par contre, sur x86, elle sera codée par défaut

Code :

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

1
2
3
4
5
 
[0] x
[1] padding
[2] LSB y (adresse paire)
[3] MSB y

car l'accès 16-bit sur adresse paire est plus rapide (en une fois 16-bit), mais il est possible (au prix d'une réduction de performances : accès en 2 fois 8-bit) de compresser la structure comme ceci :

Code :

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

1
2
3
4
 
[0] x
[1] LSB y (adresse impaire)
[2] MSB y

[- Robby -]

Neitsa ... ça fait longtemps pardi !
Oups, on a pris du galon ici ... respect ici !
Bon ...
Merci pour ta réponse.
Oui, je connais et j'utilise le fichier d'en-tête pshpack1.h.

Il est certain que la directive "#pragma pack (push,1)" force le compilateur à aligner les champs de la structure sur le byte. Mais ... et je vais essayer de me faire comprendre, c'est pas toujours facile uniquement par écrit ... le compilateur considère-t-il que le fait de découper physiquement la structure en 2 moitiés constitue, pour la 2eme moitié, une forme d'alignement ? L'alignement concerne des "ajustements" de 2, 4 ou 8 bytes ... mais si le compilateur, pour des raisons qui lui sont propres (gestion mémoire, peu importe) décide de placer la 2eme moitié de ma structure à l'autre bout du segment de données ... considère-t-il qu'il s'agit aussi d'un alignement, et donc que cela lui est interdit ?

Oui, je cherche le "fin du fin" ici ... mais parfois, c'est intéressant de savoir exactement ce qu'il se passe. Surtout ici, dans mon cas.

Voila, que penses-tu de ma remarque Neitsa ?
Confirmes-tu que "#pragma pack (push,1)" suffit à interdire, dans tous les cas, toutes formes de morcellement de la structure ?

Merci à toi

Edit :
désolé Mr Delahaye, nous avons "posté" en même temps.
==> " l'alignement n'a rien à voir avec la contigüité "
Je suis d'accord avec ça !

[Emmanuel Delahaye]

Edit :
désolé Mr Delahaye, nous avons "posté" en même temps.
==> " l'alignement n'a rien à voir avec la contigüité "
Je suis d'accord avec ça !

Ah bon ? Parce qu'à te lire, tu as toujours l'air de croire que le C autorise le compilateur à découper la structure en parties non contigües ou dans des segments différents. Ce n'est pas le cas. Il autorise l'alignement (et donc le padding ou bourrage), c'est tout.

Je le répète, la contigüité est garantie (elle inclue le bourrage éventuel). Bien sûr, la taille maximale d'un objet (bourrage inclus) est définie par le compilateur. Elle ne peut être inférieure à 32767 en C90 et 65535 en C99.

[- Robby -]

Parce qu'à te lire, tu as toujours l'air de croire que le C autorise le compilateur à découper la structure en parties non contigües ou dans des segments différents. Ce n'est pas le cas. Il autorise l'alignement (et donc le padding ou bourrage), c'est tout.

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait. Donc, ce n'est pas le cas ? Ah bon ... savais pas.

Donc, "#pragma pack (push,1)" suffit bien à interdire toutes formes d'alignements ... de padding et de "non-contiguité" !

Merci beaucoup !

[Emmanuel Delahaye]

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait.

Non. En C, on a pas accès à la mémoire physique, du moins de manière standard. On ne connait que la mémoire 'logique' (les 'adresses' sont en réalité des identificateurs numériques qui n'ont que très rarement une réalité physique, MMU oblige...)

Donc, "#pragma pack (push,1)" suffit bien à interdire toutes formes d'alignements ... de padding et de "non-contiguité" !

• C'est écrit dans la doc de ton compilateur
• Ce n'est pas portable.

[- Robby -]

on a pas accès à la mémoire physique, du moins de manière standard. On ne connait que la mémoire 'logique'.

Oui, oui, je sais ça.

C'est écrit dans la doc de ton compilateur

Ah bon ... ? ... La doc de mon Compilateur ? Y'a une doc avec mon compilateur ? ... J'utilise VS C++ 2008, et puisqu'on parle d'emplacement physique, elle est ou cette doc ? Dans la librairie msdn qui va avec ?

[Emmanuel Delahaye]

Oui, oui, je sais ça.

Alors cesse de sortir des énormités comme ça :

Oui, je pensais que C pouvait gérer la disposition physique en mémoire comme il le désirait.

admets simplement que tu t'es trompé c'est tout.

La doc de mon Compilateur ? Y'a une doc avec mon compilateur ?

Oui.

J'utilise VS C++ 2008, et puisqu'on parle d'emplacement physique, elle est ou cette doc ? Dans la librairie msdn qui va avec ?

Pas dans la partie bibliothèque (library), évidemment, mais dans la section VC++, oui, certainement. Il faut que je cherche à ta place ou tu vas y arriver tout seul ?

[- Robby -]

Oui, je me suis mal exprimé, en effet.
Comment C pourrait-il gérer la mémoire physique !!!
C'est en effet une énormité.
J'admets

Je pense pouvoir y arriver tout seul !

Entre nous, je suis déjà allé voir dans la doc msdn, un peu partout. On y parle en effet de "#pragma pack". On en parle en termes d'alignemets. Mais je n'ai trouvé nul part d'info concernant la "non-(non-contigüité)".

EDIT
----
Ok, j'ai compris !
Je viens de me rendre compte que ... bien que "sachant" ... je confonds gestion "logique" et "physique" de la mémoire. Quand on a compris "ça" ... il devient évident que "#pragma pack 1" suffit à rendre la structure "logiquement" contigüe.

[Emmanuel Delahaye]

Entre nous, je suis déjà allé voir dans la doc msdn, <...> Mais je n'ai trouvé nul part d'info concernant la "non-(non-contigüité)".

Double négation ? Je suis perdu (pas assez de neurones, désolé). Si tu parles de la contigüité, c'est dans la norme qui définit le langage C.

http://emmanuel-delahaye.developpez.com/notes.htm#norme

[- Robby -]

je suis perdu (pas assez de neurones, désolé)

J'en doute

concernant la "non-(non-contigüité)"

Concernant le fait que "#pragma pack 1" empeche la non-contigüité en mémoire ... logique.

J'ai édité mon article précédent ... le "franc" est tombé.

[Emmanuel Delahaye]

Concernant le fait que "#pragma pack 1" empeche la non-contigüité en mémoire ... logique.

Je ne comprends pas cette histoire de non contigüité. Ca n'existe pas. Point. Le C garanti la contigüité. Elle inclue les éventuels bytes de bourrage liés à l'implémentation. Point.

Ca ne dépend ni de la nature de la mémoire (physique, logique, qui est une question système qui n'a rien à voir avec le C), ni des directives ou configurations d'alignement ou de compression qui sont des caractéristiques de l'implémentation.

C'est clair cette fois ? Je ne veux plus entendre parler de "non-contigüité", ça n'existe pas.

[- Robby -]

OK !

Il s'agit alors d'une caractéristique du language C.

Il semble que Pascal n'offre pas cette "indiscutabilité".
L'existence en Pascal de "Packed Record", ainsi que sa définition, en est la preuve. Pascal dans ce cas, ne parle pas uniquement d'alignement mais également de structure rendue de cette façon "mono-bloc".

"Point" donc ! si cela est votre souhait.

Merci pour cet échange.

[Emmanuel Delahaye]

Il s'agit alors d'une caractéristique du language C.

Tu comprends vite, mais il faut t'expliquer longtemps... language ?

Il semble que Pascal n'offre pas cette "indiscutabilité".
L'existence en Pascal de "Packed Record", ainsi que sa définition, en est la preuve. Pascal dans ce cas, ne parle pas uniquement d'alignement mais également de structure rendue de cette façon "mono-bloc".

Hors-sujet.

http://www.developpez.net/forums/forumdisplay.php?f=21

[- Robby -]

Tu comprends vite, mais il faut t'xpliquer longtemps...

Votre condescendance n'apporte rien au débat.

Non, l'équivalent Pascal n'est pas "hors-sujet".
Cela était même la base même de ma question.
L'équivalence de l'un et de l'autre.

Je vous remercie bien sincèrement pour votre aide,
et vous présente mon "point", mais cette fois le mien.

respect.

[Elijha]

Je ne connais pas la portabilité de "__attribute__((packed))", mais j'utilise ceci (avec gcc linux/windows):

Code :

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

1
2
3
4
5
6
7
// Structure d'un message CAN
struct stCanMsg
{
  unsigned short id :11 ;
  unsigned char dlc : 4 ;
  unsigned char data[8] ;
} __attribute__((packed)) ;

[Médinoc]

__attribute__((packed)) c'est du GCC.

Code C :

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
#ifdef < un define caractéristique de GCC. __GNUC__ peut-être ? >
#define ATTRIBUTE_PACKED __attribute__((packed))
#else
#define ATTRIBUTE_PACKED
#endif
 
...
 
// Structure d'un message CAN
#ifdef _MSC_VER
#include <pshpack1.h>
#endif
struct stCanMsg
{
  unsigned short id :11 ;
  unsigned char dlc : 4 ;
  unsigned char data[8] ;
} ATTRIBUTE_PACKED;
#ifdef _MSC_VER
#include <poppack.h>
#endif