Decalage elemantaire

Salut a tous
J'ai un leger probleme de decalage, dans le cadre d'une appli d'image re recupere des pixels couleurs sur 32 bits avec 24 bit de données.

Code:

---

00 << rien 00<< rouge 00<<vert 00<<bleu

---

Je cherche à isoler les couleurs alors betement je masque et decale

Code:

---

1 2 3

char blue = (char) (*lpSrc & 0x000000ff) ; int color = blue; *lpDest = color;

---

Et hop ça marche pô :( a la place du rouge j'ai du blanc ( 0xff ) c'est mon & qui fait pas ce que je pensse ?? ou ya une subtilité que je n'ai pas saisie ??

Quel est le type de ldSrc et ldDest ? int*, je suppose ?
Dans ton code, je ne vois pas ou tu fais le decalage ? Ca se fait avec << et >>, normalement.
Pour ce qui est de ta conversion en char, je ne comprends pas non plus... Tu supposes peut-etre qu'un char fait 8 bits ? (pour couper toute remarque: un char fait au moins 8 bits, mais peut faire plus suivant l'architecture).

En fait ya pas de decalage pendant le post j'ai tester avec un simple masque pour voir si c'etait pa lier simplement au fameux decalage...

Niveau char je suis sur du Windows Mobile sur ARM et les char font 8bits
et simplemnt avec le masque ça me colle des 1 partout :(

lpSrc c'est un LPDWORD == unsigned long *

Il y a des normes pour les tailles des variables et un char c'est 8 bits !!! il n'y a que le int qui vari selon les micro 16 bits ou 32 bits mais pas autre chose !

mais il est préferable de metre des unsigned char !

Code:

---

00 << rien 00<< rouge 00<<vert 00<<bleu

---

il n'y aurai pas une erreur à ce niveau la ?! ils font tous 00 ?! ou c'est moi qui comprend pas.

Question bete... Les char, ils sont signed ou unsigned par defaut sur ta machine ?

EDIT:

Citation:

---

Il y a des normes pour les tailles des variables et un char c'est 8 bits !!!

---

C'est au moins 8 bits. Peut-etre plus suivamt l'envie des concepteurs de l'architecture. C'est dans la FAQ...

:bravo: je suis un boulet effectivement il sont signed par defaut et jusqu'a preuve du contraire les couers c'est 0->255 merci je vais me faire fouetez moi :sm:

Bon voilà ça c'est réglé, comme j'ai mes trois couleur dasn des char je souhaite les recomposées sur 32 bits
rien|rouge|vert|bleu y'a t'il un moyen simple de faire ça ???
sans faire

Code:

---

1 2 3 4 5 6

unsigned long color = red; color<<16; color | red; color << 8; color | blue;

---

par defaut ils sont signer, et non un char c'est 8 bits, l'architecture n'a rien a voir la dedans, si c'est une architecture 16bits il calculera comme avec un int, mais si tu met une valeur plus grande que 8bits le compilateur mettra une warning et peut etre une erreur, ca marchera bien entendu mais ca sera plus considérer comme un char !!!

Citation:

---

Envoyé par Drahl

non un char c'est 8 bits, l'architecture n'a rien a voir la dedans

---

Ben si : Quelle est la taille d'un char? et l'article suivant. Certaines architectures ne peuvent adresser que des objets de 32 bits, par exemple, char compris. Evidemment, ca court pas les rues...

Citation:

---

Envoyé par Drahl

et non un char c'est 8 bits, l'architecture n'a rien a voir la dedans

---

Non justement. Un char c'est bien "au moins 8 bits", mais pas forcément 8 bits.

Lis la fin de la première page de ce thread :
http://www.developpez.net/forums/vie...er=asc&start=0

Drahl << La macro CHAR_BITS, elle sert a quoi, alors ? A faire joli ?

chronos << Tu peux faire le calcul en une seule ligne, mais ca sera toujours le meme calcul...

Code:

---

unsigned long int color = (red << 16) + (green << 8) + blue;

---

en supposant que res, green et blue soient des unsigned char.

EDIT: oups, j'avais pas vu que tu avais utilise un | alors que j'avais fait +. Changerait-ce quelque chose ?
De plus, il faut definir color comme "unsigned long int, meme si ton compilateur utilise le type int par defaut. C'est plus propre et conforme...

oki merci je vous laisse à vos debat philosophiques chez moi un char ça fait 8 bits

Citation:

---

Envoyé par MSDN WIN CE

char 1 signed char –128 to 127
unsigned char 1 none 0 to 255

---

Apres sur les autres archi et OS je n'en sais rien

Citation:

---

Envoyé par alveric

EDIT: oups, j'avais pas vu que tu avais utilise un | alors que j'avais fait +. Changerait-ce quelque chose ?
De plus, il faut definir color comme "unsigned long int, meme si ton compilateur utilise le type int par defaut. C'est plus propre et conforme...

---

Oki msi de mon cote ma doc me dit que int depend de l'archi (normal) et un long ça fait 32 bits point barre, pour le + je suppose que c'est la meme chose :s

et j'ai un doute sur le

Code:

---

unsigned long int color = (red << 16) + (green << 8) + blue;

---

red<<16 ça vuet dire qu ered a deja ete converti sur 32 bit ! sinon il va m'en manquer !

vous etes en train de dire que les char peuvent faire 16bits, mais non un char fait 8 bits, c'est juste que le micro n'a pas la possibilité de les traités donc il les prend comme de la taille la plus petite qu'il peut (byte = multiplet : plus petit espace mémoire adressable ) mais ton compilo il va quand mm te génerer une erreur si tu utilise un char avec des valeurs supérieur a 255, il faudra passer par ce qu'a ecrit alveric avec la macro pour eviter l'erreur (ou le warning), mais la définition propre d'un char c'est "8 bits" !

ce que tu ma fait lire gamdwin ca confirme ce que je di !!

Citation:

---

Envoyé par Drahl

mais la définition propre d'un char c'est "8 bits" !

---

Non, la definition propre d'un char c'est 1 byte, qui fait au moins 8 bits. En gros, on est tous d'accord, mais pas d'accord pour dire qu'on est d'accord...

Citation:

---

Envoyé par chronos

Oki msi de mon cote ma doc me dit que int depend de l'archi (normal) et un long ça fait 32 bits point barre,

---

Je voulais dire, que "unsigned lon" est un tpye incomplet. Les anciennes versions du C supposent le type int par defaut dans ce cas, mais maintenant (depuis C99 ?) il faut indiquer le type complet.

Citation:

---

Envoyé par chronos

pour le + je suppose que c'est la meme chose :s

---

Quoique... Un ou binaire est peut-etre un tantinet plus rapide qu'une somme. Mais ca serait du chipotage... (a moins de faire la conversion un grand nombre de fois)

Citation:

---

Envoyé par chronos

et j'ai un doute sur le

Code:

---

unsigned long int color = (red << 16) + (green << 8) + blue;

---

red<<16 ça vuet dire qu ered a deja ete converti sur 32 bit ! sinon il va m'en manquer !

---

Arg ! Tu as raison ! Et le pire c'est que j'ai lu ca il y a pas deux jours, honte a moi ! ( ici pour ceux que ca interesse)

Code:

---

1 2 3

unsigned long int color = blue; color |= ((unsigned long int)green) << 8; color |= ((unsigned long int)red) << 16;

---

Citation:

---

Envoyé par Drahl

vous etes en train de dire que les char peuvent faire 16bits, mais non un char fait 8 bits, c'est juste que le micro n'a pas la possibilité de les traités donc il les prend comme de la taille la plus petite qu'il peut (byte = multiplet : plus petit espace mémoire adressable ) mais ton compilo il va quand mm te génerer une erreur si tu utilise un char avec des valeurs supérieur a 255, il faudra passer par ce qu'a ecrit alveric avec la macro pour eviter l'erreur (ou le warning), mais la définition propre d'un char c'est "8 bits" !

---

Si, un char peut faire 16 bits.
Et tu peux lire la norme du C pour t'en convaicre, un char faut au minimum 8 bits mais peut etre plus grand sur certaines architectures, et mettre une valeur superieure a 255 sur ces architectures est correct et ne produira pas d'erreur (eventuellement un warning pour cause de portabilite).

Par contre utilse des char pour stocker des valeurs necessitant plus de 8 bits n'est franchement pas recommande car tu perds en portabilite.

Citation:

---

Envoyé par Drahl

vous etes en train de dire que les char peuvent faire 16bits,

---

Oui, ça dépend de l'architecture... DSP TMS320C54 (Texas Instrument) :

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

/********************************************************************/ /* LIMITS.H v3.10 */ /* Copyright (c) 1993-1998 Texas Instruments Incorporated */ /********************************************************************/ #ifndef _LIMITS #define _LIMITS   #define CHAR_BIT 16 /* NUMBER OF BITS IN TYPE CHAR */ #define SCHAR_MAX 32767 /* MAX VALUE FOR SIGNED CHAR */ #define SCHAR_MIN (-SCHAR_MAX-1) /* MIN VALUE FOR SIGNED CHAR */ #define UCHAR_MAX 65535u /* MAX VALUE FOR UNSIGNED CHAR */ #define CHAR_MIN SCHAR_MIN /* MIN VALUE FOR CHAR */ #define CHAR_MAX SCHAR_MAX /* MAX VALUE FOR CHAR */ #define MB_LEN_MAX 1   #define SHRT_MAX 32767 /* MAX VALUE FOR SHORT */ #define SHRT_MIN (-SHRT_MAX-1) /* MIN VALUE FOR SHORT */ #define USHRT_MAX 65535u /* MAX VALUE FOR UNSIGNED SHORT */   #define INT_MAX 32767 /* MAX VALUE FOR INT */ #define INT_MIN (-INT_MAX-1) /* MIN VALUE FOR INT */ #define UINT_MAX 65535u /* MAX VALUE FOR UNSIGNED INT */   #define LONG_MAX 2147483647 /* MAX VALUE FOR LONG */ #define LONG_MIN (-LONG_MAX-1) /* MIN VALUE FOR LONG */ #define ULONG_MAX 4294967295 /* MAX VALUE FOR UNSIGNED LONG */   #endif

---

Citation:

---

<...>mais la définition propre d'un char c'est "8 bits" !

---

Non. On peut dire '8-bits utilisables de manière standard', mais l'encombrement peut être supérieur.