Discussion :

[Médinoc]

Plus ou moins. Pas exactement, mais il y a quelques similitudes.

[Emmanuel Delahaye]

Emmanuel Delahaye, ton exemple me plait beaucoup mais j'ai du mal a le comprendre.

http://emmanuel-delahaye.developpez.com/tad.htm

[contremaitre]

merci

[corrector]

calloc ne garantis pas la mise à NULL ...enfin c'est ce que j'ai compris en lisant les nombreux postes traitant du "all bits zero" et de cette fameuse "trap representation" ....peut être que je me trompe c'est plus une confirmation que j'attends

Et tu as parfaitement raison : la représentation d'un pointeur nul n'est pas forcément tous les bits à 0.

[Thierry Chappuis]

calloc ne garantis pas la mise à NULL ...enfin c'est ce que j'ai compris en lisant les nombreux postes traitant du "all bits zero" et de cette fameuse "trap representation" ....peut être que je me trompe c'est plus une confirmation que j'attends

Tu as raison, rien ne garantit que NULL est représenté avec tous les bits à zéro. Dans ce contexte, il n'est pas possible de se fier à calloc() pour initialiser un tableau de pointeur ou un tableau de flottants à une valeur nulle (NULL ou 0.0 respectivement). C'est en revanche OK pour les entiers.

EDIT: Oups, désolé corrector, ça m'apprendra à répondre sans avoir lu le fil jusqu'à la fin

Thierry

[Emmanuel Delahaye]

Dans ce contexte, il n'est pas possible de se fier à calloc() pour initialiser un tableau de pointeur ou un tableau de flottants à une valeur nulle (NULL ou 0.0 respectivement). C'est en revanche OK pour les entiers.

Pour char, et les entiers non signés, oui. Pour les autre type entiers, C99 admet la possibilité d'une 'trap représentation' et ne dit pas que all-bit-to-zero ne peut pas en être une. (désolé pour les négations...)

[orfix]

Merci pour vos confirmations !

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation" ainsi que "le bit padding" ...

Merci !

[Emmanuel Delahaye]

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation"

En gros, une combinaison de bits interdite provoquant une exception (trap ou 'piège').

ainsi que "le bit padding"

Je connais le bit stuffing utilisé en codage numérique réseau et le byte padding qui est le remplissage placé entre les éléments d'une structure pour garantir l'alignement...

[diogene]

n1124 :

6.2.6.2 Integer types
.....
5 The values of any padding bits are unspecified.45) A valid (non-trap) object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. For any integer type, the object representation where all the bits are zero shall be a representation of the value zero in that type.

[corrector]

J'aimerais avoir une petite explication sur ce qu'est réellement "une trap representation" ainsi que "le bit padding"

trap representation : état mémoire d'un objet de type T :

1. qui ne correspond pas à la représentation d'une valeur de T,
2. et qui, s'il est interprété par le processeur comme étant du type T, provoquera une erreur

Par exemple, sur les certaines machines représentant les entiers signés en signe-magnitude, la représentation "zéro négatif" peut être une trap representation. Une variable int non initialisée pourra avoir un tel état. Tenter de la lire provoquera une exception processeur (= trap).

Plus répandu de nos jours : sur un processeur x86, charger un pointeur non valide dans un registre d'adresse peut provoquer une erreur.

unsigned char n'a pas de trap representation, et permet d'examiner la mémoire; mais signed char et char peuvent avoir des "trap representation"!

padding bits : bits appartenant aux bytes d'un objet (sizeof(T) bytes pour un objet de type T), mais qui ne contribuent pas à la représentation de la valeur de l'objet : quel que soit l'état de ces bits, la valeur représentée est la même.

S'il un type T a des bits de padding (= remplissage/rembourrage), deux objets de type T de même valeur n'auront pas forcément la même représentation; si a et b sont de type T, on peut avoir la propriété :

a == b && memcmp (&a, &b, sizeof a) != 0

Copier une variable d'un tel type pourra soit copier tous les bits y compris ceux de padding, soit ne pas modifier les bits de padding de la cible, soit faire n'importe quoi sur ces bits.

Ce qui implique qu'on ne peut pas, en général, comparer la valeur des objets avec memcmp.

char, et ses variantes signées et non-signées, ne peuvent pas avoir de padding bits.

[gl]

char, et ses variantes signées et non-signées, ne peuvent pas avoir de padding bits.

Pour unsigned char, je suis d'acord. Par contre je n'ai rien trouve qui empeche signed char d'avoir des padding bits.

1 - For unsigned integer types other than unsigned char, the bits of the object representation shall be divided into two groups: value bits and padding bits (there need not be any of the latter). If there are N value bits, each bit shall represent a different power of 2 between 1 and 2N−1, so that objects of that type shall be capable of representing values from 0 to 2N − 1 using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.44)

2 - For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit.

[orfix]

S'il un type T a des bits de padding (= remplissage/rembourrage), deux objets de type T de même valeur n'auront pas forcément la même représentation; si a et b sont de type T, on peut avoir la propriété :

a == b && memcmp (&a, &b, sizeof a) != 0

je vois mieux pourquoi la comparaison bit à bit est très déconseillée

Merci à tous

[contremaitre]

Bonjour,

est ce que ça pose un problème de déclarer

Code :

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

1
2
3
4
5
6
7
8
 
struct x
{
   int *a;
   int *b;
   int **c;
   int taille2;
};

dans x.h au lieu de x.c, pour ensuite dans le main faire p->a pour accéder à a plutôt que de devoir créer une fonction x_geta pour chaque tableau (a,b,c etc...)

Car j'ai besoin de ces tableaux pour les donner à d'autres fonctions. Je ne peux pas me permettre de faire des fonctions dans le TAD (comme le dit médinoc, ou comme expliqué ici http://emmanuel-delahaye.developpez.com/tad.htm) qui elles accèdent aux données car je devrais alors réécrire tous mes algos de traitement qui prennent en entrée un int * par exemple.

[Thierry Chappuis]

Cela ne pose à priori pas de problème. Tout dépend en fait de quel degré d'encapsulation des données tu désires avoir. Si le code client accède directement aux champs de la structure, tout changement ultérieur de cette structure pourrait devenir difficile à mettre en oeuvre.

Thierry

[contremaitre]

en fait ce qui est surtout important pour moi, c'est de faciliter l'allocation (et désallocation) mémoire de mes tableaux.

Et mettre ces fonctions dans une fichier séparé, je trouve ça pratique.
Donc si je peux aussi accéder aux membres de ma structure directement c'est ce dont j'ai besoin pour ce problème.

[Thierry Chappuis]

en fait ce qui est surtout important pour moi, c'est de faciliter l'allocation (et désallocation) mémoire de mes tableaux.

Et mettre ces fonctions dans une fichier séparé, je trouve ça pratique.
Donc si je peux aussi accéder aux membres de ma structure directement c'est ce dont j'ai besoin pour ce problème.

En quoi le fait de rendre la structure interne de ton TAD public facilite l'allocation et la désallocation de mémoire?

Thierry

[contremaitre]

En quoi le fait de rendre la structure interne de ton TAD public facilite l'allocation et la désallocation de mémoire?

Thierry

Non, ce qui facilite la (dés)allocation, c'est d'avoir des fonctions comme x_create ou x_delete qui s'en occupent.

Par contre le fait de rentre la structure publique facilite l'accés à mes tableaux pour les passer à mes différents algos qui prennent en paramètre un int* par exemple.
Sinon, pour chaque tableau il me faudrait créer une fonction get

[contremaitre]

Code :

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

1
2
3
4
5
6
 
      /* tout a 0 */
      {
         static const struct x z = { 0 };
         *self = z;
      }

Est ce que ça initialise les pointeurs à NULL de faire ça?
(les pointeurs à l'intérieur de la structure je parle)

[Médinoc]

Oui.

[Thierry Chappuis]

Est ce que ça initialise les pointeurs à NULL de faire ça?

Ca initialise tous les champs de la structure à la valeur nulle adéquate i.e. NULL pour un pointeur, 0 pour un entier, 0.0 pour un flottant de type double, etc.

Thierry