"Alexandre BACQUART" a écrit dans le message de news:40eaea3f$0$18110$
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Hé bien je dirais que c'est un abus de langage de la part des constructeurs et qu'il faudrait que ça change, sinon c'est de la publicité mensongère pour ton DSP truc :)
-- Tek
Jean-Noël Mégoz wrote:
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message de
news:40eaea3f$0$18110$626a14ce@news.free.fr...
Au passage, le K&R en français a traduit ça par "octet", ce qui est
évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de
"octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD
de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même
ici, la taille du byte peut changer ?
Hé bien je dirais que c'est un abus de langage de la part des
constructeurs et qu'il faudrait que ça change, sinon c'est de la
publicité mensongère pour ton DSP truc :)
"Alexandre BACQUART" a écrit dans le message de news:40eaea3f$0$18110$
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Hé bien je dirais que c'est un abus de langage de la part des constructeurs et qu'il faudrait que ça change, sinon c'est de la publicité mensongère pour ton DSP truc :)
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', "Jean-Noël Mégoz" wrote:
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD
Dans le contexte de programmation *en langage C*. On a rien dit de plus.
de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Peut être. Ici, on ne parle que de machine virtuelle. Jamais de machine physique.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Jean-Noël Mégoz" <nospam_jnmegoz@infonie.fr> wrote:
Dans un contexte de programmation, byte n'est peut-être pas équivalent de
"octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD
Dans le contexte de programmation *en langage C*. On a rien dit de plus.
de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même
ici, la taille du byte peut changer ?
Peut être. Ici, on ne parle que de machine virtuelle. Jamais de machine
physique.
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD
Dans le contexte de programmation *en langage C*. On a rien dit de plus.
de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Peut être. Ici, on ne parle que de machine virtuelle. Jamais de machine physique.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Richard Delorme
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int. Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous les bits d'un codage UTF-8 dans un int.
Pas nécessairement. La norme n'impose une étendue de valeurs que pour les encodages sur un seul byte. La valeur pour un caractère multi-byte dépend de l'implémentation et il n'y a donc pas nécessairement de correspondance entre le nombre de byte du caractère et la valeur que retourne sa mise entre "single-quote".
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
A mon avis, le type wchar_t est surtout pratique pour manipuler des caractères qui ne sont pas présents dans le "source character set".
-- Richard
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte
character" entre les "single-quote". Si é est écrit sur plusieurs bytes,
cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8
d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int.
Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous
les bits d'un codage UTF-8 dans un int.
Pas nécessairement. La norme n'impose une étendue de valeurs que pour
les encodages sur un seul byte. La valeur pour un caractère multi-byte
dépend de l'implémentation et il n'y a donc pas nécessairement de
correspondance entre le nombre de byte du caractère et la valeur que
retourne sa mise entre "single-quote".
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie
du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce
que permet le int standard. C'est pour cela que le wchar_t ont été inventé
et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
A mon avis, le type wchar_t est surtout pratique pour manipuler des
caractères qui ne sont pas présents dans le "source character set".
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int. Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous les bits d'un codage UTF-8 dans un int.
Pas nécessairement. La norme n'impose une étendue de valeurs que pour les encodages sur un seul byte. La valeur pour un caractère multi-byte dépend de l'implémentation et il n'y a donc pas nécessairement de correspondance entre le nombre de byte du caractère et la valeur que retourne sa mise entre "single-quote".
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
A mon avis, le type wchar_t est surtout pratique pour manipuler des caractères qui ne sont pas présents dans le "source character set".
-- Richard
Gabriel Dos Reis
cedric writes:
| Gabriel Dos Reis wrote: | > | En tous cas, pour un entier : | > | | (x + 256) & 255 == x & 255 | > Faux. | | Uniquement en complément à deux, ou si x est positif, non ?
[#4] Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |, collectively described as bitwise operators) are required to have operands that have integer type. These operators return values that depend on the internal representations of integers, and have implementation-defined and undefined aspects for signed types.
Le point est que tu peux avoir un problème d'extension de sign.
-- Gaby
cedric <rixed@happyleptic.NOSPAM.org> writes:
| Gabriel Dos Reis wrote:
| > | En tous cas, pour un entier :
| > | | (x + 256) & 255 == x & 255
| > Faux.
|
| Uniquement en complément à deux, ou si x est positif, non ?
[#4] Some operators (the unary operator ~, and the binary
operators <<, >>, &, ^, and |, collectively described as
bitwise operators) are required to have operands that have
integer type. These operators return values that depend on
the internal representations of integers, and have
implementation-defined and undefined aspects for signed
types.
Le point est que tu peux avoir un problème d'extension de sign.
| Gabriel Dos Reis wrote: | > | En tous cas, pour un entier : | > | | (x + 256) & 255 == x & 255 | > Faux. | | Uniquement en complément à deux, ou si x est positif, non ?
[#4] Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |, collectively described as bitwise operators) are required to have operands that have integer type. These operators return values that depend on the internal representations of integers, and have implementation-defined and undefined aspects for signed types.
Le point est que tu peux avoir un problème d'extension de sign.
-- Gaby
Gabriel Dos Reis
Eric Lévénez writes:
| Le 6/07/04 9:10, dans <40ea4fee$0$306$, | « Richard Delorme » a écrit : | | > Rappel : en C, 'é' est de type int. | | Rappel : 'é' est illégal,
T'as trouvé ça où ?
-- Gaby
Eric Lévénez <news@levenez.com> writes:
| Le 6/07/04 9:10, dans <40ea4fee$0$306$7a628cd7@news.club-internet.fr>,
| « Richard Delorme » <abulmo@nospam.fr> a écrit :
|
| > Rappel : en C, 'é' est de type int.
|
| Rappel : 'é' est illégal,
En 40ead644$0$18118$, Alexandre BACQUART va escriure:
C'est quoi un "byte" d'après la norme ?
FAQ, question 16.2 (partie 4/4 actuellement)
Antoine
Antoine Leca
En 40eafd6d$0$24435$, Jean-Noël Mégoz va escriure:
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Bon, ce n'est pas le sujet du groupe, mais tu viens de trouver tout seul et sans le vouloir une unité de taille variable (un peu comme les mesures ds drapiers d'avant la Révolution).
Pour ta MEV de 128 "megabytes", un "byte" vaut 134 217 728 / 128 000 000 soit 1,048 576 octet.
Pour ton disque dur de 40 gigabytes, un "byte" vaut bien 1 octet.
(Et le plus drôle, c'est la disquette de 1.44 M: elle a 1440 kibioctets, donc 1 474 560 octets. Ce qui fait que le "M" vaut 1 024 000.)
Antoine
En 40eafd6d$0$24435$636a15ce@news.free.fr, Jean-Noël Mégoz va escriure:
Dans un contexte de programmation, byte n'est peut-être pas
équivalent de "octet", mais d'un point de vue matériel, une RAM de
128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40
gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Bon, ce n'est pas le sujet du groupe, mais tu viens de trouver tout seul et
sans le vouloir une unité de taille variable (un peu comme les mesures ds
drapiers d'avant la Révolution).
Pour ta MEV de 128 "megabytes", un "byte" vaut
134 217 728 / 128 000 000 soit 1,048 576 octet.
Pour ton disque dur de 40 gigabytes, un "byte" vaut bien 1 octet.
(Et le plus drôle, c'est la disquette de 1.44 M: elle a 1440 kibioctets,
donc 1 474 560 octets. Ce qui fait que le "M" vaut 1 024 000.)
En 40eafd6d$0$24435$, Jean-Noël Mégoz va escriure:
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
Bon, ce n'est pas le sujet du groupe, mais tu viens de trouver tout seul et sans le vouloir une unité de taille variable (un peu comme les mesures ds drapiers d'avant la Révolution).
Pour ta MEV de 128 "megabytes", un "byte" vaut 134 217 728 / 128 000 000 soit 1,048 576 octet.
Pour ton disque dur de 40 gigabytes, un "byte" vaut bien 1 octet.
(Et le plus drôle, c'est la disquette de 1.44 M: elle a 1440 kibioctets, donc 1 474 560 octets. Ce qui fait que le "M" vaut 1 024 000.)
Antoine
Antoine Leca
En BD10B1F8.552C%, Eric Lévénez va escriure:
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser de compiler. Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement. En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement. En 24 bits, en 64 bits, etc.
Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
Non et non.
Le problème pour tout caractère qui dévie du jeu de base, c'est tout simplement qu'il peut ne pas exister dans le jeu d'exécution, ce qui rendrait le programme incompilable (et cela concerne $, @, ¤ et quelques autres).
wchar_t a été inventé pour tenter de faciliter la programmation des algorithmes avec les caractères multibytes (utilisé en japonais bien avant que l'idée de UTF-8 ne surgisse dans le tête de Ken Thompson). Lors de la normalisation ANSI, cette idée fut introduite dans la norme, selon moi pour acheter le vote favorable des non-Américains. Mais la norme n'a pas été suffisament loin (par exemple, il est possible, et courant, d'avoir des wchar_t sur 8 bits, ce qui rend idiot toute utilisation d'yceux); alors même que le modèle de programmation proposé n'était pas suffisament attrayant pour être mis en pratique par les Américains programmant en C (avec des exceptions comme GCC).
En 1995 il y eut une tentative (d'origine japonaise) de corriger ce dernier point et d'offrir une bibliothèque plus étendue, mais cela n'a pas pris pour une conjugaison de facteurs: - C était déjà sur une pente descendante; - le modèle était complexe et permettait mal de reprendre tel quel le code existant; - le modèle valait aussi bien pour le modèle Unicode (encodage unifié des caractères) que le traditionnel (lire, Sun) *nix où les wchar_t sont une mise à plat des traditionnels multibytes, où 'é' change de code quand tu changes de locales - le modèle ne s'est pas bien adapté au standard émergent, Unicode, en partie à cause de la guéguerre 16-32 bits qui sévissait à cette époque (et qui s'est résolue aujourd'hui par la nécessité d'avoir DEUX formes de stockage des caractères, une sur 16 et l'autre sur 32 bits).
Antoine
En BD10B1F8.552C%news@levenez.com, Eric Lévénez va escriure:
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte
character" entre les "single-quote". Si é est écrit sur plusieurs
bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs
octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un
char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou
induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser
de compiler.
Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te
retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement.
En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement.
En 24 bits, en 64 bits, etc.
Mais si
j'utilise des caractères chinois par exemple, ce n'est plus 2 octets,
mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646,
ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ?
Je connais des caractères en 6 octets (U6000000 pour le premier d'entre
eux), mais en 5...
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de
caractères. Pour le moment, ils en ont identifié environ 100 000...
On aurait le même problème avec d'autres encodages comme l'UTF-32 et
une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source
sont codés sur 32 bits, je veux voir...
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère
qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus
de place que ce que permet le int standard. C'est pour cela que le
wchar_t ont été inventé et qu'il a une taille assez grande pour
pouvoir représenter tout caractère.
Non et non.
Le problème pour tout caractère qui dévie du jeu de base, c'est tout
simplement qu'il peut ne pas exister dans le jeu d'exécution, ce qui
rendrait le programme incompilable (et cela concerne $, @, ¤ et quelques
autres).
wchar_t a été inventé pour tenter de faciliter la programmation des
algorithmes avec les caractères multibytes (utilisé en japonais bien avant
que l'idée de UTF-8 ne surgisse dans le tête de Ken Thompson). Lors de la
normalisation ANSI, cette idée fut introduite dans la norme, selon moi pour
acheter le vote favorable des non-Américains. Mais la norme n'a pas été
suffisament loin (par exemple, il est possible, et courant, d'avoir des
wchar_t sur 8 bits, ce qui rend idiot toute utilisation d'yceux); alors même
que le modèle de programmation proposé n'était pas suffisament attrayant
pour être mis en pratique par les Américains programmant en C (avec des
exceptions comme GCC).
En 1995 il y eut une tentative (d'origine japonaise) de corriger ce dernier
point et d'offrir une bibliothèque plus étendue, mais cela n'a pas pris pour
une conjugaison de facteurs:
- C était déjà sur une pente descendante;
- le modèle était complexe et permettait mal de reprendre tel quel le code
existant;
- le modèle valait aussi bien pour le modèle Unicode (encodage unifié des
caractères) que le traditionnel (lire, Sun) *nix où les wchar_t sont une
mise à plat des traditionnels multibytes, où 'é' change de code quand tu
changes de locales
- le modèle ne s'est pas bien adapté au standard émergent, Unicode, en
partie à cause de la guéguerre 16-32 bits qui sévissait à cette époque (et
qui s'est résolue aujourd'hui par la nécessité d'avoir DEUX formes de
stockage des caractères, une sur 16 et l'autre sur 32 bits).
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser de compiler. Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement. En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement. En 24 bits, en 64 bits, etc.
Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
Non et non.
Le problème pour tout caractère qui dévie du jeu de base, c'est tout simplement qu'il peut ne pas exister dans le jeu d'exécution, ce qui rendrait le programme incompilable (et cela concerne $, @, ¤ et quelques autres).
wchar_t a été inventé pour tenter de faciliter la programmation des algorithmes avec les caractères multibytes (utilisé en japonais bien avant que l'idée de UTF-8 ne surgisse dans le tête de Ken Thompson). Lors de la normalisation ANSI, cette idée fut introduite dans la norme, selon moi pour acheter le vote favorable des non-Américains. Mais la norme n'a pas été suffisament loin (par exemple, il est possible, et courant, d'avoir des wchar_t sur 8 bits, ce qui rend idiot toute utilisation d'yceux); alors même que le modèle de programmation proposé n'était pas suffisament attrayant pour être mis en pratique par les Américains programmant en C (avec des exceptions comme GCC).
En 1995 il y eut une tentative (d'origine japonaise) de corriger ce dernier point et d'offrir une bibliothèque plus étendue, mais cela n'a pas pris pour une conjugaison de facteurs: - C était déjà sur une pente descendante; - le modèle était complexe et permettait mal de reprendre tel quel le code existant; - le modèle valait aussi bien pour le modèle Unicode (encodage unifié des caractères) que le traditionnel (lire, Sun) *nix où les wchar_t sont une mise à plat des traditionnels multibytes, où 'é' change de code quand tu changes de locales - le modèle ne s'est pas bien adapté au standard émergent, Unicode, en partie à cause de la guéguerre 16-32 bits qui sévissait à cette époque (et qui s'est résolue aujourd'hui par la nécessité d'avoir DEUX formes de stockage des caractères, une sur 16 et l'autre sur 32 bits).
Antoine
Emmanuel Delahaye
In 'fr.comp.lang.c', "Antoine Leca" wrote:
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2
J'aurais dit 16 bits non ?
millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
soit 65536 caractères... Y'a sûrement un truc qui m'a echappé.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Antoine Leca" <root@localhost.gov> wrote:
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2
J'aurais dit 16 bits non ?
millions de caractères. Pour le moment, ils en ont identifié environ 100
000...
soit 65536 caractères... Y'a sûrement un truc qui m'a echappé.
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2
J'aurais dit 16 bits non ?
millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
soit 65536 caractères... Y'a sûrement un truc qui m'a echappé.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Eric Lévénez
Le 7/07/04 15:55, dans <ccgvfr$5jj$, « Antoine Leca » a écrit :
En BD10B1F8.552C%, Eric Lévénez va escriure:
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser de compiler. Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement. En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement. En 24 bits, en 64 bits, etc.
Où est-il marqué dans la norme que tout type d'encodage des caractères sous la forme 'x' doit obligatoirement tenir sur un int ?
Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation interne sur 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
La norme UTF-8 indique que l'on peut encoder un caractère en 1, 2, 3, 4 ou 5 octets. Cela n'a rien à voir (enfin presque), avec la représentation interne du caractère en Unicode, par exemple, sur 16 ou 32 bits.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
Non, là tu confonds la représentation interne Unicode 4 avec l'encodage UTF-8 qui nécessite l'utilisation de bits d'encodage dans chaque octet.
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et l'UTF-8. De plus il n'est nullement nécessaire d'avoir une représentation interne autre que l'UTF-8, et donc même l'unicode 4 peut être utilisé sur des architectures 16 bits, en faisant juste attention à ne pas utiliser des choses du type 'é'.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 7/07/04 15:55, dans <ccgvfr$5jj$1@shakotay.alphanet.ch>, « Antoine Leca »
<root@localhost.gov> a écrit :
En BD10B1F8.552C%news@levenez.com, Eric Lévénez va escriure:
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte
character" entre les "single-quote". Si é est écrit sur plusieurs
bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs
octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un
char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou
induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser
de compiler.
Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te
retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement.
En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement.
En 24 bits, en 64 bits, etc.
Où est-il marqué dans la norme que tout type d'encodage des caractères sous
la forme 'x' doit obligatoirement tenir sur un int ?
Mais si
j'utilise des caractères chinois par exemple, ce n'est plus 2 octets,
mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646,
ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation interne
sur 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ?
Je connais des caractères en 6 octets (U6000000 pour le premier d'entre
eux), mais en 5...
La norme UTF-8 indique que l'on peut encoder un caractère en 1, 2, 3, 4 ou 5
octets. Cela n'a rien à voir (enfin presque), avec la représentation interne
du caractère en Unicode, par exemple, sur 16 ou 32 bits.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de
caractères. Pour le moment, ils en ont identifié environ 100 000...
Non, là tu confonds la représentation interne Unicode 4 avec l'encodage
UTF-8 qui nécessite l'utilisation de bits d'encodage dans chaque octet.
On aurait le même problème avec d'autres encodages comme l'UTF-32 et
une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source
sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et l'UTF-8. De
plus il n'est nullement nécessaire d'avoir une représentation interne autre
que l'UTF-8, et donc même l'unicode 4 peut être utilisé sur des
architectures 16 bits, en faisant juste attention à ne pas utiliser des
choses du type 'é'.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 7/07/04 15:55, dans <ccgvfr$5jj$, « Antoine Leca » a écrit :
En BD10B1F8.552C%, Eric Lévénez va escriure:
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char
Oui, mais ce n'est un problème que dans le cas d'une affectation (directe ou induite) vers un char.
ou d'un int.
Non. Défini par l'implémentation ne permet pas à l'implémentation de refuser de compiler. Si tes int sont sur 16 bits (étrange avec UTF-8, mais enfin), tu vas te retrouver avec 0xC3A9 ou 0xA9C3, suivant les plateformes. Sans débordement. En 32 bits, ce sera 0xC3A9 ou 0xA9C30000, là encore sans débordement. En 24 bits, en 64 bits, etc.
Où est-il marqué dans la norme que tout type d'encodage des caractères sous la forme 'x' doit obligatoirement tenir sur un int ?
Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8)
Mmmm, sauf à utiliser un jeu de caractères différent de Unicode/ISO 10646, ou encore d'anciennes et obsolètes versions, la limite est réellement de 4.
Là tu parles non plus de l'encodage UTF-8 mais de la représentation interne sur 4 octets.
Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets
Un exemple ? Je connais des caractères en 6 octets (U6000000 pour le premier d'entre eux), mais en 5...
La norme UTF-8 indique que l'on peut encoder un caractère en 1, 2, 3, 4 ou 5 octets. Cela n'a rien à voir (enfin presque), avec la représentation interne du caractère en Unicode, par exemple, sur 16 ou 32 bits.
(même si en Unicode 4 tout caractère tient sur 4 octets,
Avec 4 octets, tu as un espace d'adressage de 21 bits, plus de 2 millions de caractères. Pour le moment, ils en ont identifié environ 100 000...
Non, là tu confonds la représentation interne Unicode 4 avec l'encodage UTF-8 qui nécessite l'utilisation de bits d'encodage dans chaque octet.
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Une implémentation sur une architecture 16 bits où les caractères du source sont codés sur 32 bits, je veux voir...
Là encore tu confonds la représentation interne en Unicode et l'UTF-8. De plus il n'est nullement nécessaire d'avoir une représentation interne autre que l'UTF-8, et donc même l'unicode 4 peut être utilisé sur des architectures 16 bits, en faisant juste attention à ne pas utiliser des choses du type 'é'.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
