Et la ça ne compile plus !!
Pourtant ça ne me parait pas tellement différent.
(dans la mesure ou les 2 types pointés font la même taille).
Du coup je suis obligé de faire un cast.
unsigned char * puc = (unsigned char *) pc;
a la mode C ou
unsigned char * puc = reinterpret_cast<unsigned char *>(pc);
a la mode C++
car
unsigned char * puc = static_cast<unsigned char *>(pc);
ne fonctionne pas non plus.
Du coup je suis obligé d'avoir dans mon code, un cast qui donne
l'impression que je fais une grosse bidouille alors qu'en fait non (en
tout cas pas plus que dans le 1er exemple).
Quand on travaille sur des bitmaps, unsigned char est tout à fait indiqué.
Mais la plupart des fonctions utilisées ne savent pas qu'il s'agit de bitmaps.
En fait, sauf dans les cas particuliers où on s'intéresse à la valeur numérique des pixels (pour faire des opérations arithmétiques), le type le plus logique serait void* : on transfère un gros bloc de mémoire du fichier vers la RAM, puis vers la mémoire vidéo.
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
Mais en gros : Si le code en question sait que c'est du texte, il utilise char. S'il sait que c'est des bitmaps, il utilise unsigned char. De même s'il doit y faire quelque chose de précis en le considérant de la mémoire brute. S'il ne sait rien en ce qui concerne le contenu (ou n'en veut rien savoir), c'est void.
AMHA, évidemment. Ce sont des conventions plutôt que quelque chose imposé par le langage.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 2 Feb 2006 01:39:47 -0800, "kanze" <kanze@gabi-soft.fr>:
Quand on travaille sur des bitmaps, unsigned char est tout à
fait indiqué.
Mais la plupart des fonctions utilisées ne savent pas qu'il
s'agit de bitmaps.
En fait, sauf dans les cas particuliers où on s'intéresse à la
valeur numérique des pixels (pour faire des opérations
arithmétiques), le type le plus logique serait void* : on
transfère un gros bloc de mémoire du fichier vers la RAM, puis
vers la mémoire vidéo.
Si on le transfère vers la mémoire vidéo, on sait bien qu'il
s'agit d'un bitmap, non ?
Mais en gros : Si le code en question sait que c'est du texte,
il utilise char. S'il sait que c'est des bitmaps, il utilise
unsigned char. De même s'il doit y faire quelque chose de précis
en le considérant de la mémoire brute. S'il ne sait rien en ce
qui concerne le contenu (ou n'en veut rien savoir), c'est void.
AMHA, évidemment. Ce sont des conventions plutôt que quelque
chose imposé par le langage.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Quand on travaille sur des bitmaps, unsigned char est tout à fait indiqué.
Mais la plupart des fonctions utilisées ne savent pas qu'il s'agit de bitmaps.
En fait, sauf dans les cas particuliers où on s'intéresse à la valeur numérique des pixels (pour faire des opérations arithmétiques), le type le plus logique serait void* : on transfère un gros bloc de mémoire du fichier vers la RAM, puis vers la mémoire vidéo.
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
Mais en gros : Si le code en question sait que c'est du texte, il utilise char. S'il sait que c'est des bitmaps, il utilise unsigned char. De même s'il doit y faire quelque chose de précis en le considérant de la mémoire brute. S'il ne sait rien en ce qui concerne le contenu (ou n'en veut rien savoir), c'est void.
AMHA, évidemment. Ce sont des conventions plutôt que quelque chose imposé par le langage.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Fabien LE LEZ wrote:
On 2 Feb 2006 01:39:47 -0800, "kanze" :
Dans la pratique, ça serait une bêtise de ne pas utiliser les flux s'ils conviennent, pour des raisons de portabilité, ou simplement pour ne pas réinventer la roue.
J'ai eu de gros problèmes de performances avec les fstream. Mais ça vient peut-être du fait que mon compilo est obsolète : avec FILE*, je ne suis pas très loin d'obtenir la vitesse des fonctions de l'API Win32.
Tout dépend de ce qu'on veut faire. Pour des blocs de données binaire, j'évite en effet les fstream. Dans les implémentations classiques, l'utilisation de filebuf directement pouvait parfois donner de la portabilité ; dans les flux standard, il faut se méfier des effets du locale imbué en plus. Mais dans l'ensemble, dans de tels cas, je me rebats la plupart du temps à l'interface du SE -- dans mon cas, Posix est de toute façon plus portable que le C++. (C-à-d qu'il y a plus de variation entre les compilateurs C++ qu'entre les implémentations Posix, et que toutes les plateformes qui m'intéressent professionnellement sont Posix, ou lui ressemble -- Linux s'approche plus à Posix que la plupart des compilateurs dits C++ s'approche à ISO 14882.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 2 Feb 2006 01:39:47 -0800, "kanze" <kanze@gabi-soft.fr>:
Dans la pratique, ça serait une
bêtise de ne pas utiliser les flux s'ils conviennent, pour
des raisons de portabilité, ou simplement pour ne pas
réinventer la roue.
J'ai eu de gros problèmes de performances avec les fstream.
Mais ça vient peut-être du fait que mon compilo est obsolète :
avec FILE*, je ne suis pas très loin d'obtenir la vitesse des
fonctions de l'API Win32.
Tout dépend de ce qu'on veut faire. Pour des blocs de données
binaire, j'évite en effet les fstream. Dans les implémentations
classiques, l'utilisation de filebuf directement pouvait parfois
donner de la portabilité ; dans les flux standard, il faut se
méfier des effets du locale imbué en plus. Mais dans l'ensemble,
dans de tels cas, je me rebats la plupart du temps à l'interface
du SE -- dans mon cas, Posix est de toute façon plus portable
que le C++. (C-à-d qu'il y a plus de variation entre les
compilateurs C++ qu'entre les implémentations Posix, et que
toutes les plateformes qui m'intéressent professionnellement
sont Posix, ou lui ressemble -- Linux s'approche plus à Posix
que la plupart des compilateurs dits C++ s'approche à ISO
14882.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dans la pratique, ça serait une bêtise de ne pas utiliser les flux s'ils conviennent, pour des raisons de portabilité, ou simplement pour ne pas réinventer la roue.
J'ai eu de gros problèmes de performances avec les fstream. Mais ça vient peut-être du fait que mon compilo est obsolète : avec FILE*, je ne suis pas très loin d'obtenir la vitesse des fonctions de l'API Win32.
Tout dépend de ce qu'on veut faire. Pour des blocs de données binaire, j'évite en effet les fstream. Dans les implémentations classiques, l'utilisation de filebuf directement pouvait parfois donner de la portabilité ; dans les flux standard, il faut se méfier des effets du locale imbué en plus. Mais dans l'ensemble, dans de tels cas, je me rebats la plupart du temps à l'interface du SE -- dans mon cas, Posix est de toute façon plus portable que le C++. (C-à-d qu'il y a plus de variation entre les compilateurs C++ qu'entre les implémentations Posix, et que toutes les plateformes qui m'intéressent professionnellement sont Posix, ou lui ressemble -- Linux s'approche plus à Posix que la plupart des compilateurs dits C++ s'approche à ISO 14882.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 3 Feb 2006 00:39:39 -0800, "kanze" :
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas balancer autre chose sur une carte vidéo moderne.
D'autre part, un bitmap est une suite de paquets de bits (et de padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5 bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire que "unsigned char" correspond plus que "char" n'a pas vraiment de sens.
On 3 Feb 2006 00:39:39 -0800, "kanze" <kanze@gabi-soft.fr>:
Si on le transfère vers la mémoire vidéo, on sait bien qu'il
s'agit d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas
balancer autre chose sur une carte vidéo moderne.
D'autre part, un bitmap est une suite de paquets de bits (et de
padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5
bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire
que "unsigned char" correspond plus que "char" n'a pas vraiment de
sens.
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas balancer autre chose sur une carte vidéo moderne.
D'autre part, un bitmap est une suite de paquets de bits (et de padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5 bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire que "unsigned char" correspond plus que "char" n'a pas vraiment de sens.
kanze
Fabien LE LEZ wrote:
On 3 Feb 2006 00:39:39 -0800, "kanze" :
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas balancer autre chose sur une carte vidéo moderne.
Quand on ne sait pas, c'est void* qui convient. Sauf qu'on ne peut pas faire grand chose avec void -- si on veut réelement accéder à la mémoire (brute -- sans considération de la sémantique du contenu), c'est unsigned char* qui convient, au moins en C. (En C++, je crois que char peut aussi faire l'affaire.)
Dans la pratique, plus d'une fois, je me suis servi de uint16_t ou de uint32_t. Formellement, la norme (C) n'en garantit pas l'existance. Mais dans la pratique, sur les machines qui m'intéressent... Il y a des algorithmes (MD5/SHA1, des CRC classiques, etc.) qui s'en servent, et parfois, c'est avantageux de boucler quatre fois moins. En revanche, évidemment, il faut préter attention à l'alignement.
D'autre part, un bitmap est une suite de paquets de bits (et de padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5 bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire que "unsigned char" correspond plus que "char" n'a pas vraiment de sens.
unsigned char, dans le sens que c'est le type pour la mémoire brute. Sinon, uint16_t. (Il y a aussi des cas où on a 8 bits rouge, vert, bleu et 8 bits d'alpha. Et uint32_t convient très bien.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 3 Feb 2006 00:39:39 -0800, "kanze" <kanze@gabi-soft.fr>:
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit
d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas
balancer autre chose sur une carte vidéo moderne.
Quand on ne sait pas, c'est void* qui convient. Sauf qu'on ne peut pas
faire grand chose avec void -- si on veut réelement accéder à la
mémoire
(brute -- sans considération de la sémantique du contenu), c'est
unsigned char* qui convient, au moins en C. (En C++, je crois que char
peut aussi faire l'affaire.)
Dans la pratique, plus d'une fois, je me suis servi de uint16_t ou de
uint32_t. Formellement, la norme (C) n'en garantit pas l'existance.
Mais
dans la pratique, sur les machines qui m'intéressent... Il y a des
algorithmes (MD5/SHA1, des CRC classiques, etc.) qui s'en servent, et
parfois, c'est avantageux de boucler quatre fois moins. En revanche,
évidemment, il faut préter attention à l'alignement.
D'autre part, un bitmap est une suite de paquets de bits (et de
padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5
bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire
que "unsigned char" correspond plus que "char" n'a pas vraiment de
sens.
unsigned char, dans le sens que c'est le type pour la mémoire brute.
Sinon, uint16_t. (Il y a aussi des cas où on a 8 bits rouge, vert,
bleu
et 8 bits d'alpha. Et uint32_t convient très bien.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Si on le transfère vers la mémoire vidéo, on sait bien qu'il s'agit d'un bitmap, non ?
On s'en doute, disons. Mais je ne suis pas sûr qu'on ne puisse pas balancer autre chose sur une carte vidéo moderne.
Quand on ne sait pas, c'est void* qui convient. Sauf qu'on ne peut pas faire grand chose avec void -- si on veut réelement accéder à la mémoire (brute -- sans considération de la sémantique du contenu), c'est unsigned char* qui convient, au moins en C. (En C++, je crois que char peut aussi faire l'affaire.)
Dans la pratique, plus d'une fois, je me suis servi de uint16_t ou de uint32_t. Formellement, la norme (C) n'en garantit pas l'existance. Mais dans la pratique, sur les machines qui m'intéressent... Il y a des algorithmes (MD5/SHA1, des CRC classiques, etc.) qui s'en servent, et parfois, c'est avantageux de boucler quatre fois moins. En revanche, évidemment, il faut préter attention à l'alignement.
D'autre part, un bitmap est une suite de paquets de bits (et de padding), dont la taille n'est pas forcément 8. Si tu as du 5-5-5-1 (5 bits de bleu, 5 bits de vert, 5 bits de rouge, 1 bit de padding), dire que "unsigned char" correspond plus que "char" n'a pas vraiment de sens.
unsigned char, dans le sens que c'est le type pour la mémoire brute. Sinon, uint16_t. (Il y a aussi des cas où on a 8 bits rouge, vert, bleu et 8 bits d'alpha. Et uint32_t convient très bien.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
