Concaténation,Cast et bitfield

Version imprimable

05/05/2008, 16h10
Darick

Concaténation,Cast et bitfield

Bonjours a tous. J'aurais besoin d'un petit coup de mains au sujet
d'une optimisation que je suis en train de réalisé.
Je vous fait un petit résumé pour que vous compreniez mieux:
Je travail dans le traitement d'image et l'application de ces traitements dans le commerce vers des produits innovant et de haute technologie.Je ne suis donc pas débutant en développement.
Actuellement je m'acharne a mettre en place un traitement d'image rapide efficace et peu cher, et surtout rapide et tenant le moins de place possible en mémoire(oui si on veut que se soit pas cher ^^).
Après plusieurs test concluant le traitement est totalement en place et en cours d'optimisation dans l'objectif d'une réduction de cout.

Le principe:
Après analyse d'une image on crée un prototype de l'image sous un format de
2 tableau de 4*20 pour les x et 4*15 pour les y. ces tableaux sont des tableaux contenant une structure sous formes de champs de bites:

struct Pixel
{
char bit0:1;
char bit1:1;
char bit2:1;
char bit3:1;
char bit4:1;
char bit5:1;
char bit6:1;
char bit7:1;
};

cette structure permet de stocker 8 pixels qui sont tous en binaire (donc au final on a 2 tableau de 4*160 et 4*120 bit)
Ce format a été tester et montre qu'il est bien plus light en mémoire que un tableau de caractère, car bien plus simple a initialisé.

Le seul souci actuel est que je doit parcourir l'intégralité du tableau et tester chaque pixel par rapport au 4 précédents.

Donc un souci se passe quand on est sur :bit0,bit1 et bit3.

J'ai donc penser a concaténer 2 structures en convertissant chacune de ses structures en char. Seulement le hic est la: est il possible simplement de convertir cette structure en char par cast ou autre.

Merci de vos réponses.
05/05/2008, 16h23
Thierry Chappuis

Les champs de bits ne s'utilisent en principe qu'avec les type int, signed int ou unsigned int.

Thierry
05/05/2008, 17h15
diogene

Citation:

J'ai donc penser a concaténer 2 structures en convertissant chacune de ses structures en char. Seulement le hic est la: est il possible simplement de convertir cette structure en char par cast ou autre.

Je ne pense pas qu'on puisse convertir par un cast une structure en un entier. Il faudra passer par des pointeurs. On peut aussi envisager une union.

La difficulté réside dans la portabilité du code vu que l'ordre des champs de bits est dépendant de l'implantation (du LSB ->MSB ou l'inverse)
05/05/2008, 17h22
Darick

Citation:

Les champs de bits ne s'utilisent en principe qu'avec les type int, signed int ou unsigned int

en effet seulement on peu également les utiliser avec des char ou les short cela ne pose aucun soucie, seulement la plupart des gens préfere prendre un char et le décalé plutot que d'utiliser un champ de bite. Le probleme de plus ne réside pas dans la possibilité de faire un champ de bite en char mais sur la concaténation de deux de ces champs de bite.

Citation:

Je ne pense pas qu'on puisse convertir par un cast une structure en un entier.

oui sinon sa serais bien trop simple j'ai envie de dire. Et j'ai déjà expérimenté les cast et tenté de faire ma propre fonction de cast mais sans grand succès.

Citation:

La difficulté réside dans la portabilité du code

oui les bitefield pose des problemes de portabilités, seulement dans mon cas il n'y a pas besoin de portabilité car tout ce fait en interne du programme et il n'y a qu'une affectation de données dans ces bitefields.

J'ai tenter également de convertir à l'instant les 8 bits disponible en un char
mais sans aucun succes non plus.
05/05/2008, 17h25
Darick

Citation:

Il faudra passer par des pointeurs. On peut aussi envisager une union.

faire une union des 2 structures peu être interressante, peu tu développé ton idée stp.
Mais je ne sais pas si cela est un peu risqué et long en temps de traitement.
05/05/2008, 18h22
Emmanuel Delahaye

Citation:

Envoyé par Darick

soucie, <...> champ de bite <...> champs de bite. <...> oui les bitefield <...> bitefields.

Attention à cette sale manie de mettre des 'e' en plus un peu partout... Sur certains mots, ça fait un peu... étrange...
05/05/2008, 18h24
Emmanuel Delahaye

Citation:

Envoyé par diogene

Je ne pense pas qu'on puisse convertir par un cast une structure en un entier. Il faudra passer par des pointeurs.

Pas de pointeurs sur les champs de bits.
05/05/2008, 18h26
Emmanuel Delahaye
Citation:
Envoyé par Darick

Le principe:
Après analyse d'une image on crée un prototype de l'image sous un format de
2 tableau de 4*20 pour les x et 4*15 pour les y. ces tableaux sont des tableaux contenant une structure sous formes de champs de bites:

Code:

1 2 3 4 5 6 7 8 9 10 11 12 struct Pixel { char bit0:1; char bit1:1; char bit2:1; char bit3:1; char bit4:1; char bit5:1; char bit6:1; char bit7:1; };
Mauvais choix. Utilise plutôt des tableaux de unsigned char et les opérateurs binaires, c'est fait pour et c'est portable. Comment crois-tu que sont implémentés les accès aux champs de bits sur une machine où l'unité de mémoire est l'octet, si ce n'est à coup de bitwise operators ?

Autant le faire soit même et garder la main sur le mécanisme et son optimisation (c'est aussi un peu à ça que sert le C...).
05/05/2008, 18h32
Thierry Chappuis

Citation:

Envoyé par Darick

en effet seulement on peu également les utiliser avec des char ou les short cela ne pose aucun soucie,

La norme ne pense pas comme toi. Si tu veux manipuler des bits, utilises plutôt un tableau de unsigned chars et les opérateurs de manipulation de bits, c'est fait pour.

Thierry
05/05/2008, 18h55
diogene

Citation:

Envoyé par Emmanuel Delahaye

Pas de pointeurs sur les champs de bits.

Pas sur les champs de bit bien sûr, sur la structure et le unsigned char.

Darick

Citation:

oui les bitefield pose des problemes de portabilités, seulement dans mon cas il n'y a pas besoin de portabilité car tout ce fait en interne du programme et il n'y a qu'une affectation de données dans ces bitefields.

Mais il peut y avoir une incohérence entre la position (présumée) des bits dans la structure et celle dans le unsigned char.

Citation:

faire une union des 2 structures peu être interressante, peu tu développé ton idée stp.
Mais je ne sais pas si cela est un peu risqué et long en temps de traitement.

Je ne pense pas que cela affecte le temps de traitement, la différentiation se faisant au moment de la compilation. Mais, cela n'enlève pas le problème de portabilité.

C'est sûr qu'Emmanuel a raison en te disant de coder sur un unsigned char au lieu d'une structure avec champ de bits. Je suis d'ailleurs un peu étonné que tu obtiennes ainsi des performances notoirement meilleures.

Bonjour,

voilà un morceau de code qui montre comment effectuer un cast Pixel->char, puis char->Pixel.

On retombe bien sur la même valeur d'origine, mais la valeur de char* intermédiaire dépend de ton système/architecture/etc...

Par contre, si char a == char b, alors Pixel a == Pixel b, et si char a != char b, alors Pixel a != Pixel b.

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
60
61
62
63
64
65
66
67
68
69
70
#include <string.h>
#include <stdio.h>
 
typedef struct
{
    char bit0:1;
    char bit1:1;
    char bit2:1;
    char bit3:1;
    char bit4:1;
    char bit5:1;
    char bit6:1;
    char bit7:1;
} Pixel;
 
int main()
{
    Pixel px[4];
    int i = 0;
 
    /* On met différentes valeurs dans chaque pixel, la flemme de faire long */
    *(char*)(void*)(px) = 'h';
    *((char*)(void*)(px)+1) = 'e';
    *((char*)(void*)(px)+2) = 'l';
    *((char*)(void*)(px)+3) = 'l';
 
    for (i = 0; i < 4; i++)
    {
        printf("Pixel %d:\n", i);
        printf("\t%d\n", px[i].bit0);
        printf("\t%d\n", px[i].bit1);
        printf("\t%d\n", px[i].bit2);
        printf("\t%d\n", px[i].bit3);
        printf("\t%d\n", px[i].bit4);
        printf("\t%d\n", px[i].bit5);
        printf("\t%d\n", px[i].bit6);
        printf("\t%d\n", px[i].bit7);
    }
 
    /* On met dans un tableau char */
    char ch_px[4];
    memcpy(ch_px, px, 4); /* strncpy(ch_px, (char*)(void*)(px), 4) */
 
    puts("==================================");
    puts("==================================");
    /* affiche hell */
    printf("Chaine de char: %c%c%c%c\n", ch_px[0], ch_px[1], ch_px[2], ch_px[3]);
 
    /* On remet ça dans un tableau de Pixels */
    Pixel px_2[4];
    memcpy(px_2, ch_px, 4); /* strncpy((char*)(void*)(px_2), ch_px, 4) */
 
    puts("==================================");
    puts("==================================");
 
    for (i = 0; i < 4; i++)
    {
        printf("Pixel %d:\n", i);
        printf("\t%d\n", px_2[i].bit0);
        printf("\t%d\n", px_2[i].bit1);
        printf("\t%d\n", px_2[i].bit2);
        printf("\t%d\n", px_2[i].bit3);
        printf("\t%d\n", px_2[i].bit4);
        printf("\t%d\n", px_2[i].bit5);
        printf("\t%d\n", px_2[i].bit6);
        printf("\t%d\n", px_2[i].bit7);
    }
 
    return 0;
}

Regarde le code, les résultats sont ceux attendus.

Edit: Bien sûr, si jamais il existe des architectures ou un char ne fait pas 8 bits, alors ce code a toutes les chances de planter sur ces architectures.

Citation:

Envoyé par coyotte507

Bonjour,

voilà un morceau de code qui montre comment effectuer un cast Pixel->char, puis char->Pixel.

Pas du C...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
Project   : Forums
Compiler  : GNU GCC Compiler (called directly)
Directory : D:\dev\forums\
--------------------------------------------------------------------------------
Switching to target: default
Compiling: main.c
main.c:17: warning: function declaration isn't a prototype
main.c: In function `main':
main.c:18: error: `Pixel' undeclared (first use in this function)
main.c:18: error: (Each undeclared identifier is reported only once
main.c:18: error: for each function it appears in.)
main.c:18: error: syntax error before "px"
main.c:21: error: `px' undeclared (first use in this function)
main.c:26: error: 'for' loop initial declaration used outside C99 mode
main.c:49: error: syntax error before "px_2"
main.c:50: error: `px_2' undeclared (first use in this function)
main.c:55: error: redefinition of 'i'
main.c:26: error: previous definition of 'i' was here
main.c:55: error: 'for' loop initial declaration used outside C99 mode
Process terminated with status 1 (0 minutes, 1 seconds)

Champs de bits, casts, memcpy(), la portabilité est compromise. De plus, mes char étant signés, j'obtiens ceci après correction :

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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
 
Pixel 0:
        0
        0
        0
        -1
        0
        -1
        -1
        0
Pixel 1:
        -1
        0
        -1
        0
        0
        -1
        -1
        0
Pixel 2:
        0
        0
        -1
        -1
        0
        -1
        -1
        0
Pixel 3:
        0
        0
        -1
        -1
        0
        -1
        -1
        0
==================================
==================================
Chaine de char: hell
==================================
==================================
Pixel 0:
        0
        0
        0
        -1
        0
        -1
        -1
        0
Pixel 1:
        -1
        0
        -1
        0
        0
        -1
        -1
        0
Pixel 2:
        0
        0
        -1
        -1
        0
        -1
        -1
        0
Pixel 3:
        0
        0
        -1
        -1
        0
        -1
        -1
        0
 
Press ENTER to continue.

Quel intérêt, face aux solutions classiques basées sur les unsigned char et les opérateurs bits ?

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
60
 
/* http://delahaye.emmanuel.free.fr/clib/ */
#include "ed/inc/bits.h"
 
#include <string.h>
#include <stdio.h>
 
static void print (unsigned char const *px, size_t n)
{
   int i;
   for (i = 0; i < 4; i++)
   {
      printf ("Pixel %d (%02X):\n", i, (unsigned) px[i]);
      printf ("\t%d\n", mGET (px[i], BIT (0)));
      printf ("\t%d\n", mGET (px[i], BIT (1)));
      printf ("\t%d\n", mGET (px[i], BIT (2)));
      printf ("\t%d\n", mGET (px[i], BIT (3)));
      printf ("\t%d\n", mGET (px[i], BIT (4)));
      printf ("\t%d\n", mGET (px[i], BIT (5)));
      printf ("\t%d\n", mGET (px[i], BIT (6)));
      printf ("\t%d\n", mGET (px[i], BIT (7)));
   }
}
 
int main (void)
{
   unsigned char px[4];
 
   /* On met différentes valeurs dans chaque pixel, en le castant en char */
   px[0] = 'h';
   px[1] = 'e';
   px[2] = 'l';
   px[3] = 'l';
 
   print (px, 4);
 
   {
      /* On met dans un tableau char */
      char ch_px[4];
      memcpy (ch_px, px, 4);    //strncpy(ch_px, (char*)(void*)(px), 4)
 
      puts ("==================================");
      puts ("==================================");
      /* affiche hell */
      printf ("Chaine de char: %c%c%c%c\n", ch_px[0], ch_px[1], ch_px[2],
              ch_px[3]);
 
      /* On remet ça dans un tableau de Pixels */
      {
         unsigned char px_2[4];
         memcpy (px_2, ch_px, 4); //strncpy((char*)(void*)(px_2), ch_px, 4)
 
         puts ("==================================");
         puts ("==================================");
 
         print (px, 4);
      }
   }
   return 0;
}

Ca donne :

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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
 
Pixel 0 (68):
        0
        0
        0
        1
        0
        1
        1
        0
Pixel 1 (65):
        1
        0
        1
        0
        0
        1
        1
        0
Pixel 2 (6C):
        0
        0
        1
        1
        0
        1
        1
        0
Pixel 3 (6C):
        0
        0
        1
        1
        0
        1
        1
        0
==================================
==================================
Chaine de char: hell
==================================
==================================
Pixel 0 (68):
        0
        0
        0
        1
        0
        1
        1
        0
Pixel 1 (65):
        1
        0
        1
        0
        0
        1
        1
        0
Pixel 2 (6C):
        0
        0
        1
        1
        0
        1
        1
        0
Pixel 3 (6C):
        0
        0
        1
        1
        0
        1
        1
        0
 
Press ENTER to continue.

05/05/2008, 19h50
coyotte507

Code édité, désolé :roll:
05/05/2008, 20h18
coyotte507

Ca fait ce que Darick veut (cast de Pixel en char).

En affichant les pixels deux fois, j'ai voulu montrer qu'on pouvait les copier, en tant que char, puis recaster en Pixel, et que le contenu était inchangé.

L'intérêt de manipuler des structures Pixel au lieu de char, ce n'est pas à moi qu'il faut le demander :roll:
05/05/2008, 23h38
Darick

je pense que vous vous dites que je suis fous mais en fais j'obtiens de meilleur performance car mes pixel sont en binaire et pas en nb aléatoire. Donc oui c'est vrai que un bitfield sa peu paraitre suspect pour pas mal d'entre vous en system embarqué mais j'ai une remarque: mes traitement doivent se faire avec un temps d'acces minime et un zone mémoire de 3ko maximum pour l'intégralité de l'application.

Donc étant donnée que je ne stocke que des informations binaire donc non suceptible de faire du négatif et encore moins de dépassé la taille d'un char.
J'ai pensé que mettre un champ de bit permettrait de faire une allocation plus rapide (Tab[i][j].bit0 plutot que Tab[i][j]<<8) sans décalage et donc probleme pour la suite.

Le but de mettre en place ici un champ de bite est d'accéléré la création du prototype de l'image alors que créer un tableau de char avec un system de décalage complexe imbriqué dans de multiple boucle fort alourdi le programme.

Donc mes performance sont meilleur au niveau temps et rapidité de création de plus un champ de bit est stoké dans le registre une fois affecté et donc les conditions qui en émane se traite plus rapidement.
en effet écrire if(NbPixY>=a && NbPixY<=b) prend plus de temps d'éxécution que sa : if(c.bit0) (c'est un exemple ^^)

Donc merci pour votre aide et pour le code je vais voir si il peu arranger ce que je fais sachant que je ne peux pas avoir les cas (jamais!) qu'a évoqué
notre précédant amis.

Citation:

La norme ne pense pas comme toi. Si tu veux manipuler des bits, utilises plutôt un tableau de unsigned chars et les opérateurs de manipulation de bits, c'est fait pour.

ben oui c'est fait pour mais tu verrais la chose qu'il y a derriere tu chercherais a faire autrement car c'est pas si simple que cela a expliquer de plus j'ai pas le droit non plus de tout dire sur le projet.
J'ai juste besoin d'une solution alternative ou on peu rapidement accéder a chaque bit d'une structure de la taille d'un char, donc ok un tableau de char est parfait et les opérateur par bits c'est fait pour ^^
seulement ya d'autre chose derriere qui m'ont ammener a reconsidérer cette implémentation.

Par contre j'aimerais juste que ce topic parte pas en live entre faut il ou non utiliser les champ de bit car sa c'est une discution sans fin!
sa dépend des cas et la je suis dans un cas qui me permet de considérer leur utilisation.
05/05/2008, 23h52
Darick

le soucie de ton code est que tu tiens pas compte de la place mémoire et tu rajoute si j'ai bien compris un passage par un char* et un cast dans un tableau de char. Seulement je ne dispose pas de la place nécéssaire pour me permettre d'affecter un tableau de char en plus des structures.Autant aller directement dans un tableau de char.

PS: je rapel pourquoi je tiens a mettre cela en place, cela permettrait de facilité et accélérer la création du prototype de l'image.
06/05/2008, 12h13
coyotte507

Que veux tu faire exactement?

Pour caster un Pixel en char, c'est:

Code:

char c = *((char*)(void*)&px);
06/05/2008, 15h34
Darick

le probleme c'est que je n'ai pas le droit de dire exactement ce qu'il y a derriere.

Pour caster cette structure en un char tu est sur que sa marche?
car il y a aucune erreur et les test passe mais avec difficulté j'ai l'impression, comme si l'expression que tu donnais était en fait un calcul complexe.
Ce qui est étrange.

Bon je te réexplique ce que j'ai le droit de dire.
En fait on va prendre une image en 320*240 grace a un capteur cette image est en HSL à la sortie de la rom.
On cherche donc a créer un prototype de cette image (la je ne peux pas dire comment est le prototype mais il est assez complexe) sous un format de tableau de 4*n et 4*p ou n et p sont les valeur max pour x et y.
Ces tableau contienne au final des "pixel" booléen qui sont soit orange soit noir.
On dit donc que un pixel orange est 1 et un pixel noir est 0 (en mémoire)
seulement on est dans un system ou le but est de gagner le plus de place possible en mémoire. Donc on a deux cas: utiliser un tableau de char ou chaque bit du char est un pixel ou utiliser un tableau de structure en bitfield de même dimension qu'un char.
Le bitfield semble sur le papier compliquer les chose car posant plein de pb.
Mais en réalité cela accélere et simplifie nettement les conditions qui sont dans le programme par la suite.D'ou mon gain de temps et de performance.

Seulement j'ai besoin de concaténer 2 de ses structures (j'ai donc penser a créer un int qui contindrait les 16 bit de ses deux structures comme pour un char de base)
Hélas la pose un pb: la conversion de la strucuture en un char pour pouvoir concaténer les 2 char en un int. (n effet j'ai besoin d'étudier le pixel n le n+1 le n-1 et le n-4 dans mon programme d'ou le pb)

Si tu veux tenter une union, tu peux faire quelque chose du genre :

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
typedef union
{
   struct
   {
    unsigned char bit0:1;
    unsigned char bit1:1;
    unsigned char bit2:1;
    unsigned char bit3:1;
    unsigned char bit4:1;
    unsigned char bit5:1;
    unsigned char bit6:1;
    unsigned char bit7:1;
    }field;
    unsigned char car;
}Pixel;
// exemple d'utilisation :
int main(void)
{
  int i;
  Pixel p[3];
  for(i=0;i<3; i++)p[i].car = 0;
  p[1].field.bit2 =1;
  return 0;
}

06/05/2008, 17h14
Emmanuel Delahaye

Citation:

Envoyé par Darick

En fait on va prendre une image en 320*240 grace a un capteur cette image est en HSL à la sortie de la rom.

Tu veux dire que c'est une image stockée en ROM ? C'est donc, vu du C, une variable à lecture seule ?

Citation:

On cherche donc a créer un prototype de cette image (la je ne peux pas dire comment est le prototype mais il est assez complexe) sous un format de tableau de 4*n et 4*p ou n et p sont les valeur max pour x et y.
Ces tableau contienne au final des "pixel" booléen qui sont soit orange soit noir.

Je ne vois pas trop ce que tu appelles 'prototype' pour une image... Admettons que tu veuilles créer un tableau de bits dont la valeur est 0=noir et 1=orange, par exemple. Par contre j'ai pas très bien compris le format.

4 représente quoi ?
x et y c'est quoi ?

Citation:

On dit donc que un pixel orange est 1 et un pixel noir est 0 (en mémoire)
seulement on est dans un system ou le but est de gagner le plus de place possible en mémoire. Donc on a deux cas: utiliser un tableau de char ou chaque bit du char est un pixel ou utiliser un tableau de structure en bitfield de même dimension qu'un char.

Là, je comprend mieux. Le choix logique, simple et portable, c'est le tableau de unsigned char.

Citation:

Le bitfield semble sur le papier compliquer les chose car posant plein de pb.
Mais en réalité cela accélere et simplifie nettement les conditions qui sont dans le programme par la suite.D'ou mon gain de temps et de performance.

Tu as vraiment fait des mesures comparatives ? On peut voir le code avec des unsigned char et les opérateurs bits ? Parce qu'il n'y a aucune raison que ce soit plus lent, sauf si ta machine permet d'adresse les bits un à un (comme certaines zones mémoire spéciales dans certains µC comme le 8051).

Citation:

Seulement j'ai besoin de concaténer 2 de ses structures

Comme son nom l'indique (du latin cum=avec, catena=chaine), la concaténation concerne les chaines de caractères. Ca n'a aucun sens ici.

Citation:

(j'ai donc penser a créer un int qui contindrait les 16 bit de ses deux structures comme pour un char de base)
Hélas la pose un pb: la conversion de la strucuture en un char pour pouvoir concaténer les 2 char en un int. (n effet j'ai besoin d'étudier le pixel n le n+1 le n-1 et le n-4 dans mon programme d'ou le pb)

une organisation en tableau de unsigned char et l'utilisation intelligente et maitrisée des opérateurs bits permet des traitements optimisés. Je ne vois pas toujours pas ce qu'apportent les champs de bits ici...

Donne un exemple concret de traitement qui ne dévoile pas tes petits secrets.

Citation:

Envoyé par diogene

Si tu veux tenter une union, tu peux faire quelque chose du genre :

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
typedef union
{
   struct
   {
    unsigned char bit0:1;
    unsigned char bit1:1;
    unsigned char bit2:1;
    unsigned char bit3:1;
    unsigned char bit4:1;
    unsigned char bit5:1;
    unsigned char bit6:1;
    unsigned char bit7:1;
    }field;
    unsigned char car;
}Pixel;
// exemple d'utilisation :
int main(void)
{
  int i;
  Pixel p[3];
  for(i=0;i<3; i++)p[i].car = 0;
  p[1].field.bit2 =1;
  return 0;
}

Effectivement, un union résout tout :!:

Citation:

Envoyé par coyotte507

Effectivement, un union résout tout :!:

Sauf que la norme ne garantie pas que ce qui est mis d'un coté est lisible de l'autre... Notamment, rien ne dit que ce tu appelles bit0 dans le champ de bit corresponde au bit 0 de l'unsigned char. Si tu fais ça sur un 68k PowerPC, ça va te faire drôle... Et je ne parle pas d'un DSP où les unsigned char font 16 ou 32--bit...

Disons que ça peut résoudre ton problème particulier sur une plateforme bien définie...

Sur ma machine, c'est OK (Intel x86)
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 #include <stdio.h> typedef union { struct { unsigned char bit0:1; unsigned char bit1:1; unsigned char bit2:1; unsigned char bit3:1; unsigned char bit4:1; unsigned char bit5:1; unsigned char bit6:1; unsigned char bit7:1; } field; unsigned char car; } Pixel; int main (void) { Pixel p; p.car = 0x01; /* BIT0 = 1 */ printf ("p.field.bit0 = %d\n", p.field.bit0); return 0; }
Mais je n'ai toujours pas compris en quoi c'était plus simple ou plus rapide que les opérateurs bits (qui eux, sont portables)...

06/05/2008, 17h53
Thierry Chappuis

Citation:

Envoyé par coyotte507

Effectivement, un union résout tout :!:

Bon, à priori, ce code n'est pas portable et bourré de comportements indéfinis. Donc je ne sais pas si il résoud tout.

Thierry

Pourtant SDL utilise l'union sans aucun problème et est portable (sur plus que Windows/Mac/Linux).

Par contre le bit0 du char ne correspondra pas forcément au bit0 de field (mais cela pose-t-il un problème?)

Concernant la concaténation (le problème du PO), pourquoi vouloir tout mettre dans un int, un tableau de deux char/Pixels prend la même place.

Et l'union permet de comparer deux pixels, si c'est que tu veux:

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
#include <string.h>
#include <stdio.h>
 
typedef union
{
    struct
    {
        char bit0:1;
        char bit1:1;
        char bit2:1;
        char bit3:1;
        char bit4:1;
        char bit5:1;
        char bit6:1;
        char bit7:1;
    } field;
    char ch;
} Pixel;
 
int main()
{
    Pixel p[3];
 
    /* Initiliasation à partir des valeurs en bit */
    p[0].field.bit0 = 1, p[0].field.bit1 = 0, p[0].field.bit2 = 1,  p[0].field.bit3 = 1,  p[0].field.bit4 = 1,  p[0].field.bit5 = 1,  p[0].field.bit6 = 1,  p[0].field.bit7 = 1;
    p[1].field.bit0 = 1, p[1].field.bit1 = 1, p[1].field.bit2 = 1,  p[1].field.bit3 = 1,  p[1].field.bit4 = 1,  p[1].field.bit5 = 1,  p[1].field.bit6 = 1,  p[1].field.bit7 = 1;
    p[2].field.bit0 = 1, p[2].field.bit1 = 0, p[2].field.bit2 = 1,  p[2].field.bit3 = 1,  p[2].field.bit4 = 1,  p[2].field.bit5 = 1,  p[2].field.bit6 = 1,  p[2].field.bit7 = 1;
 
    if (p[0].ch == p[1].ch)
    {
        puts("p[0] == p[1]");
    }
    if (p[0].ch == p[2].ch)
    {
        puts("p[0] == p[2]");
    }
 
    return 0;
}

On aurait pu faire la même chose avec un cast barbare, mais c'est moins propre.

06/05/2008, 19h07
Thierry Chappuis

Citation:

Envoyé par coyotte507

Pourtant SDL utilise l'union sans aucun problème et est portable (sur plus que Windows/Mac/Linux).

Une union bien utilisée, c'est portable.

Thierry
06/05/2008, 19h12
coyotte507

Citation:

Envoyé par Thierry Chappuis

Une union bien utilisée, c'est portable.

Thierry

Désolé si je me trompe,

mais si on ne modifie l'union que par la structure field, et qu'on utilise le car juste pour comparer deux unions entre elle (voir si un pixel est 'égal' à l'autre), il n'y a pas de problèmes :question:

Citation:

Envoyé par coyotte507

Désolé si je me trompe,

mais si on ne modifie l'union que par la structure field, et qu'on utilise le car juste pour comparer deux unions entre elle (voir si un pixel est 'égal' à l'autre), il n'y a pas de problèmes :question:

Un champ de bit qui utilise le type char n'est déjà pas portable. Ensuite, lorsqu'on utilise une union, on ne peut accéder à la valeur de cette dernière que par le champ ayant servi à son initialisation. Ainsi, si l'initialisation se fait par le champ ch, on ne peut pas accéder à field. La norme prédit un comportement indéterminé dans ce cas.

De la même manière qu'on ne peut pas faire:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #include <stdio.h> union monUnion { float f; long n; }; int main(void) { union monUnion a; a.f = 3.1415; /* -tc- Attention: comportement indetermine */ printf("%ld\n", a.n); return 0; }
Thierry

J'ai vu ceci dans les headers de la SDL:

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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
/* Application visibility event structure */
typedef struct SDL_ActiveEvent {
	Uint8 type;	/* SDL_ACTIVEEVENT */
	Uint8 gain;	/* Whether given states were gained or lost (1/0) */
	Uint8 state;	/* A mask of the focus states */
} SDL_ActiveEvent;
 
/* Keyboard event structure */
typedef struct SDL_KeyboardEvent {
	Uint8 type;	/* SDL_KEYDOWN or SDL_KEYUP */
	Uint8 which;	/* The keyboard device index */
	Uint8 state;	/* SDL_PRESSED or SDL_RELEASED */
	SDL_keysym keysym;
} SDL_KeyboardEvent;
 
/* Mouse motion event structure */
typedef struct SDL_MouseMotionEvent {
	Uint8 type;	/* SDL_MOUSEMOTION */
	Uint8 which;	/* The mouse device index */
	Uint8 state;	/* The current button state */
	Uint16 x, y;	/* The X/Y coordinates of the mouse */
	Sint16 xrel;	/* The relative motion in the X direction */
	Sint16 yrel;	/* The relative motion in the Y direction */
} SDL_MouseMotionEvent;
 
/* Mouse button event structure */
typedef struct SDL_MouseButtonEvent {
	Uint8 type;	/* SDL_MOUSEBUTTONDOWN or SDL_MOUSEBUTTONUP */
	Uint8 which;	/* The mouse device index */
	Uint8 button;	/* The mouse button index */
	Uint8 state;	/* SDL_PRESSED or SDL_RELEASED */
	Uint16 x, y;	/* The X/Y coordinates of the mouse at press time */
} SDL_MouseButtonEvent;
 
/* Joystick axis motion event structure */
typedef struct SDL_JoyAxisEvent {
	Uint8 type;	/* SDL_JOYAXISMOTION */
	Uint8 which;	/* The joystick device index */
	Uint8 axis;	/* The joystick axis index */
	Sint16 value;	/* The axis value (range: -32768 to 32767) */
} SDL_JoyAxisEvent;
 
/* Joystick trackball motion event structure */
typedef struct SDL_JoyBallEvent {
	Uint8 type;	/* SDL_JOYBALLMOTION */
	Uint8 which;	/* The joystick device index */
	Uint8 ball;	/* The joystick trackball index */
	Sint16 xrel;	/* The relative motion in the X direction */
	Sint16 yrel;	/* The relative motion in the Y direction */
} SDL_JoyBallEvent;
 
/* Joystick hat position change event structure */
typedef struct SDL_JoyHatEvent {
	Uint8 type;	/* SDL_JOYHATMOTION */
	Uint8 which;	/* The joystick device index */
	Uint8 hat;	/* The joystick hat index */
	Uint8 value;	/* The hat position value:
			    SDL_HAT_LEFTUP   SDL_HAT_UP       SDL_HAT_RIGHTUP
			    SDL_HAT_LEFT     SDL_HAT_CENTERED SDL_HAT_RIGHT
			    SDL_HAT_LEFTDOWN SDL_HAT_DOWN     SDL_HAT_RIGHTDOWN
			   Note that zero means the POV is centered.
			*/
} SDL_JoyHatEvent;
 
/* Joystick button event structure */
typedef struct SDL_JoyButtonEvent {
	Uint8 type;	/* SDL_JOYBUTTONDOWN or SDL_JOYBUTTONUP */
	Uint8 which;	/* The joystick device index */
	Uint8 button;	/* The joystick button index */
	Uint8 state;	/* SDL_PRESSED or SDL_RELEASED */
} SDL_JoyButtonEvent;
 
/* The "window resized" event
   When you get this event, you are responsible for setting a new video
   mode with the new width and height.
 */
typedef struct SDL_ResizeEvent {
	Uint8 type;	/* SDL_VIDEORESIZE */
	int w;		/* New width */
	int h;		/* New height */
} SDL_ResizeEvent;
 
/* The "screen redraw" event */
typedef struct SDL_ExposeEvent {
	Uint8 type;	/* SDL_VIDEOEXPOSE */
} SDL_ExposeEvent;
 
/* The "quit requested" event */
typedef struct SDL_QuitEvent {
	Uint8 type;	/* SDL_QUIT */
} SDL_QuitEvent;
 
/* A user-defined event type */
typedef struct SDL_UserEvent {
	Uint8 type;	/* SDL_USEREVENT through SDL_NUMEVENTS-1 */
	int code;	/* User defined event code */
	void *data1;	/* User defined data pointer */
	void *data2;	/* User defined data pointer */
} SDL_UserEvent;
 
/* If you want to use this event, you should include SDL_syswm.h */
struct SDL_SysWMmsg;
typedef struct SDL_SysWMmsg SDL_SysWMmsg;
typedef struct SDL_SysWMEvent {
	Uint8 type;
	SDL_SysWMmsg *msg;
} SDL_SysWMEvent;
 
/* General event structure */
typedef union SDL_Event {
	Uint8 type;
	SDL_ActiveEvent active;
	SDL_KeyboardEvent key;
	SDL_MouseMotionEvent motion;
	SDL_MouseButtonEvent button;
	SDL_JoyAxisEvent jaxis;
	SDL_JoyBallEvent jball;
	SDL_JoyHatEvent jhat;
	SDL_JoyButtonEvent jbutton;
	SDL_ResizeEvent resize;
	SDL_ExposeEvent expose;
	SDL_QuitEvent quit;
	SDL_UserEvent user;
	SDL_SysWMEvent syswm;
} SDL_Event;

Donc l'union commence par un Uint8:

Code:

1
2
3
4
typedef union SDL_Event {
     Uint8 type;
     //...
} SDL_Event;

Et chaque Event différent aussi:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
/* Application visibility event structure */
typedef struct SDL_ActiveEvent {
	Uint8 type;	/* SDL_ACTIVEEVENT */
        //...
} SDL_ActiveEvent;

/* Keyboard event structure */
typedef struct SDL_KeyboardEvent {
	Uint8 type;	/* SDL_KEYDOWN or SDL_KEYUP */
	//...
} SDL_KeyboardEvent;

//...

Et pour savoir le type d'un évènement, quoique contienne l'union, on fait:

Code:

1
2
3
4
5
6
7
8
SDL_Event event;
 
//...
 
switch (event.type)
{
  ...
}

Et pourtant, même si l'union contient un évènement SDL_ActiveEvent par exemple, on peut utiliser event.type, alors que ce n'est pas le "bon" champ.

C'est bien sûr à cause du fait que chaque structure aie pour premier membre un Uint8, et donc en faisant event.type, à chaque fois on accède aux premiers 8 bits de l'union SDL_Event, ce qui signifie soit la variable "type" de l'union, soit la variable "type" de la structure correspondante.

Donc dans le cas de Pixel/char, on accède à chaque fois aux 8 premiers bits de l'union, mais c'est cette fois un comportement indéterminé?

Pour moi c'est la même chose :?

06/05/2008, 23h37
Emmanuel Delahaye

Citation:

Envoyé par coyotte507

Pourtant SDL utilise l'union sans aucun problème et est portable (sur plus que Windows/Mac/Linux).

Si la plateforme supporte la syntaxe, OK. Mais c'est pas gagné d'avance. Il faut lire la doc, tester...

En tout cas, si ça marche aussi sur les anciens Mac (68k, PowerPC), il y a certainement une compilation conditionnelle pour inverser les bits

Citation:

Par contre le bit0 du char ne correspondra pas forcément au bit0 de field (mais cela pose-t-il un problème?)

Ben oui. Si tu fais pixel.field.bit0=1 et que ça donne pixel.ch==1 (0x01) ou pixel.ch==128 (0x80) en fonction de la plateforme, c'est ce que j'appelle un problème...
06/05/2008, 23h41
Thierry Chappuis
Dans le cas où les deux champs possèdent une séquence commune, comme c'est le cas dans l'union SDL_Event que tu présentes:
Code:

1 2 3 4 5 6 7 8 9 10 /* General event structure */ typedef union SDL_Event { Uint8 type; struct SDL_ActiveEvent { Uint8 type; /*...*/ } SDL_ActiveEvent active; /*...*/ } SDL_Event;
Il est autorisé d'accéder à la valeur du champ active.type directement via le champ type. Ce cas particulier est prévu par la norme.

Citation:

Envoyé par ISO/IEC 9899:1999, &6.5.2.3

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.

Thierry
06/05/2008, 23h44
Emmanuel Delahaye

Citation:

Envoyé par coyotte507

C'est bien sûr à cause du fait que chaque structure aie pour premier membre un Uint8, et donc en faisant event.type, à chaque fois on accède aux premiers 8 bits de l'union SDL_Event, ce qui signifie soit la variable "type" de l'union, soit la variable "type" de la structure correspondante.

Donc dans le cas de Pixel/char, on accède à chaque fois aux 8 premiers bits de l'union, mais c'est cette fois un comportement indéterminé?

Pour moi c'est la même chose :?

La norme l'autorise si le premier élément des unions de structures est de même type. Si c'est le cas ici, pas de problème.

La norme dit que le comportement est indéterminé si le type est différent.

Peu importe ce que c'est 'pour toi', la norme est claire, le comportement est indéterminé. Point.
07/05/2008, 10h14
diogene

J'ai signalé, dès que j'ai parlé d'une union (post #3 et #11), que ce ne serait pas portable. Toutefois le PO semble ne pas avoir le souci de la portabilité de son code pour son application, alors ....

Emmanuel

Citation:

Mais je n'ai toujours pas compris en quoi c'était plus simple ou plus rapide que les opérateurs bits (qui eux, sont portables)...

Moi non plus; Mais c'est l'idée du PO. Ils les a peut être codé d'une façon pas très optimale ? Mystère.
13/05/2008, 11h35
Darick

Citation:

Mais je n'ai toujours pas compris en quoi c'était plus simple ou plus rapide que les opérateurs bits (qui eux, sont portables)...

je dois avouez que c'est pas plus simple ou plus rapide et que j'ai pas une préférence pour cela cependant les gens vous semblez oubliez un truc , je suis pas seul dessus et je suis pas non plus libre de tout faire car je doit etre certains que sa s'integre et que sa marche nickel avec le reste du prog.
Le reste de l'application embarqué doit obligatoirement avoir acces simplement et sans se prendre le choux a quelques valeur du tableau de pixel.

Donc si tu dit a des personnes qui bosse après toi et qui on pas la même abilitation: tenez vous faites C.Bit0 ....
le produit sera opérationnel plus vite et sans doute sans avoir a débug en mass les codes qu'ils auront pondu derriere.

Je pense que la vous pensez que je suis en solo et que je fais sa pour le fun.... mais bien sur.
Déjà le code est confidentiel je en peu rien en dire et j'ai même pas le droit de le garder sur mon PC quand je rentre chez moi donc foutre un morceau ici je pense pas que sa soit possible .... j'ai pas envie d'etre viré ^^.

Sinon grande nouvelle j'ai fini par trouver une autre solution qui mixe des tableau de char et d'autre petit truc voila bravo pour ce débat ultra constructif:!!!!
13/05/2008, 13h02
Thierry Chappuis

Rien ne t'empêche à priori de créer une couche d'abstraction qui gère tes opérations bit à bit de manière portable et qui soit simple à utiliser pour ceux qui travaillent avec toi sur ce projet.

Thierry