Les mots réservés et les délimiteurs de C++ utilisent des codes de caractères connus et bien déterminés.
Oui.
En permettant tout autre caractère (sauf les espaces et compagnie) dans les identificateurs et commentaires, il n'y a rien de spécial à traiter...
Ah ? Ben si. "tout autre caractère", ça peut être un caractère tamoul, japonais, chinois, thaïlandais, suédois, norvégien, français,...
Un caractère de ce genre a un code sur 4 octets. Il y a plein de façons d'encoder sous forme d'octets dans un fichier un caractère (UTF-8, UTF-16, UTF-32,etc.).
Il n'y a aucun moyen spécifié par la norme C++ pour spécifier l'encoding d'un fichier (usenet impose un champ dans l'entête pour le spécifier).
Comment le compilateur pourrait-il donc s'y retrouver ?
Le problème de Usenet est l'encodage varié des caractères pour transmission. Pour un compilateur sur une plate-forme donnée, ce problème n'existe pas.
??? Pourquoi ? On peut utiliser l'encoding que l'on veut sur une plateforme donnée.
-- Arnaud (Supprimez les geneurs pour me répondre)
Michel Michaud wrote:
Les mots réservés et les délimiteurs de C++ utilisent des codes de
caractères connus et bien déterminés.
Oui.
En permettant tout autre
caractère (sauf les espaces et compagnie) dans les identificateurs
et commentaires, il n'y a rien de spécial à traiter...
Ah ? Ben si. "tout autre caractère", ça peut être un caractère tamoul,
japonais, chinois, thaïlandais, suédois, norvégien, français,...
Un caractère de ce genre a un code sur 4 octets. Il y a plein de façons
d'encoder sous forme d'octets dans un fichier un caractère (UTF-8,
UTF-16, UTF-32,etc.).
Il n'y a aucun moyen spécifié par la norme C++ pour spécifier l'encoding
d'un fichier (usenet impose un champ dans l'entête pour le spécifier).
Comment le compilateur pourrait-il donc s'y retrouver ?
Le problème de Usenet est l'encodage varié des caractères pour
transmission. Pour un compilateur sur une plate-forme donnée, ce
problème n'existe pas.
??? Pourquoi ? On peut utiliser l'encoding que l'on veut sur une
plateforme donnée.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Les mots réservés et les délimiteurs de C++ utilisent des codes de caractères connus et bien déterminés.
Oui.
En permettant tout autre caractère (sauf les espaces et compagnie) dans les identificateurs et commentaires, il n'y a rien de spécial à traiter...
Ah ? Ben si. "tout autre caractère", ça peut être un caractère tamoul, japonais, chinois, thaïlandais, suédois, norvégien, français,...
Un caractère de ce genre a un code sur 4 octets. Il y a plein de façons d'encoder sous forme d'octets dans un fichier un caractère (UTF-8, UTF-16, UTF-32,etc.).
Il n'y a aucun moyen spécifié par la norme C++ pour spécifier l'encoding d'un fichier (usenet impose un champ dans l'entête pour le spécifier).
Comment le compilateur pourrait-il donc s'y retrouver ?
Le problème de Usenet est l'encodage varié des caractères pour transmission. Pour un compilateur sur une plate-forme donnée, ce problème n'existe pas.
??? Pourquoi ? On peut utiliser l'encoding que l'on veut sur une plateforme donnée.
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
Michel Michaud wrote:
Oui, mais les outils permettant de transférer les fichiers n'ont pas de problèmes avec mes accents...
Et s'il s'agit juste d'un disque partagé ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Michel Michaud wrote:
Oui, mais les outils permettant de transférer les fichiers n'ont
pas de problèmes avec mes accents...
Et s'il s'agit juste d'un disque partagé ?
--
Arnaud
(Supprimez les geneurs pour me répondre)
Oui, mais les outils permettant de transférer les fichiers n'ont pas de problèmes avec mes accents...
Et s'il s'agit juste d'un disque partagé ?
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze
Fabien LE LEZ wrote in message news:...
On Tue, 5 Oct 2004 22:48:09 -0400, "Michel Michaud" :
il faut qu'un anglais le lise et nous prouve qu'il a tout bien compris.
Pourquoi un Anglais ?
Tout à fait. Quand on a « standardisé » sur l'anglais à la SEL, c'est moi qui a dû vérifier l'anglais des anglais. (On a en fait standardisé sur l'anglais américain.)
Je vois très bien un monde où les seuls incapables de comprendre tous les autres sont les gens dont la langue maternelle est l'anglais.
Il s'agit de vérifier qu'il n'y a pas de contresens. Dans ce sens-là, c'est bien préférable qu'on fasse vérifier par quelqu'un qui maîtrise réelement la langue. Or, s'il existe bien des non anglophones qui maîtrise la langue, il y en a beaucoup pour qui ce n'est pas le cas.
En passant, il y a une chose que je n'arrive pas à comprendre. Depuis plus de vingt ans que je lis des livres techniques, le meilleur écrit, c-à-d celui dont l'anglais était le mieux, c'est bien le Josuttis et Vandevoort. Or, ni l'un ni l'autre des auteurs n'est anglophone d'origine. Je n'arrive pas à comprendre comment ils l'ont fait.
-- James Kanze GABI Software http://www.gabi-soft.fr 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 <gramster@gramster.com> wrote in message
news:<ipn6m0lddfqe2fktt6plqnp9vck7a6f6u9@4ax.com>...
On Tue, 5 Oct 2004 22:48:09 -0400, "Michel Michaud" <mm@gdzid.com>:
il faut qu'un anglais le lise
et nous prouve qu'il a tout bien compris.
Pourquoi un Anglais ?
Tout à fait. Quand on a « standardisé » sur l'anglais à la SEL, c'est
moi qui a dû vérifier l'anglais des anglais. (On a en fait standardisé
sur l'anglais américain.)
Je vois très bien un monde où les seuls incapables de comprendre tous
les autres sont les gens dont la langue maternelle est l'anglais.
Il s'agit de vérifier qu'il n'y a pas de contresens. Dans ce sens-là,
c'est bien préférable qu'on fasse vérifier par quelqu'un qui maîtrise
réelement la langue. Or, s'il existe bien des non anglophones qui
maîtrise la langue, il y en a beaucoup pour qui ce n'est pas le cas.
En passant, il y a une chose que je n'arrive pas à comprendre. Depuis
plus de vingt ans que je lis des livres techniques, le meilleur écrit,
c-à-d celui dont l'anglais était le mieux, c'est bien le Josuttis et
Vandevoort. Or, ni l'un ni l'autre des auteurs n'est anglophone
d'origine. Je n'arrive pas à comprendre comment ils l'ont fait.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
On Tue, 5 Oct 2004 22:48:09 -0400, "Michel Michaud" :
il faut qu'un anglais le lise et nous prouve qu'il a tout bien compris.
Pourquoi un Anglais ?
Tout à fait. Quand on a « standardisé » sur l'anglais à la SEL, c'est moi qui a dû vérifier l'anglais des anglais. (On a en fait standardisé sur l'anglais américain.)
Je vois très bien un monde où les seuls incapables de comprendre tous les autres sont les gens dont la langue maternelle est l'anglais.
Il s'agit de vérifier qu'il n'y a pas de contresens. Dans ce sens-là, c'est bien préférable qu'on fasse vérifier par quelqu'un qui maîtrise réelement la langue. Or, s'il existe bien des non anglophones qui maîtrise la langue, il y en a beaucoup pour qui ce n'est pas le cas.
En passant, il y a une chose que je n'arrive pas à comprendre. Depuis plus de vingt ans que je lis des livres techniques, le meilleur écrit, c-à-d celui dont l'anglais était le mieux, c'est bien le Josuttis et Vandevoort. Or, ni l'un ni l'autre des auteurs n'est anglophone d'origine. Je n'arrive pas à comprendre comment ils l'ont fait.
-- James Kanze GABI Software http://www.gabi-soft.fr 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 in message news:...
On 5 Oct 2004 00:38:24 -0700, :
charset=ISO-8859-2
Tiens, c'est quoi ce charset ?
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même pas installé sur le système d'où je poste. (Mais j'ai l'habitude que Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça existe. Je précise que je n'ai rien contre la même convention mais avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais une majuscule sur l'avant dernière lettre. En italien, le cas n'est même pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du deuxième personne s'écrivent avec une majuscule en italien -- obligatoirement pour les vouvoiements, et facultativement pour le tutoiement, et les pronoms d'objet direct ou indirect se soude après le verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On pourrait donc en construire une infinité d'exemples : « pensandoVi », « vediLe », etc.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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 <gramster@gramster.com> wrote in message
news:<t485m0tbc305mloe75cfk59c5akch3lmm0@4ax.com>...
On 5 Oct 2004 00:38:24 -0700, kanze@gabi-soft.fr:
charset=ISO-8859-2
Tiens, c'est quoi ce charset ?
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent
avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même
pas installé sur le système d'où je poste. (Mais j'ai l'habitude que
Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères
non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça
existe. Je précise que je n'ai rien contre la même convention mais
avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais
une majuscule sur l'avant dernière lettre. En italien, le cas n'est même
pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du
deuxième personne s'écrivent avec une majuscule en italien --
obligatoirement pour les vouvoiements, et facultativement pour le
tutoiement, et les pronoms d'objet direct ou indirect se soude après le
verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On
pourrait donc en construire une infinité d'exemples : « pensandoVi »,
« vediLe », etc.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même pas installé sur le système d'où je poste. (Mais j'ai l'habitude que Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça existe. Je précise que je n'ai rien contre la même convention mais avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais une majuscule sur l'avant dernière lettre. En italien, le cas n'est même pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du deuxième personne s'écrivent avec une majuscule en italien -- obligatoirement pour les vouvoiements, et facultativement pour le tutoiement, et les pronoms d'objet direct ou indirect se soude après le verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On pourrait donc en construire une infinité d'exemples : « pensandoVi », « vediLe », etc.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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 in message news:...
On 5 Oct 2004 00:38:24 -0700, :
charset=ISO-8859-2
Tiens, c'est quoi ce charset ?
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même pas installé sur le système d'où je poste. (Mais j'ai l'habitude que Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça existe. Je précise que je n'ai rien contre la même convention mais avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais une majuscule sur l'avant dernière lettre. En italien, le cas n'est même pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du deuxième personne s'écrivent avec une majuscule en italien -- obligatoirement pour les vouvoiements, et facultativement pour le tutoiement, et les pronoms d'objet direct ou indirect se soude après le verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On pourrait donc en construire une infinité d'exemples : « pensandoVi », « vediLe », etc.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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 <gramster@gramster.com> wrote in message
news:<t485m0tbc305mloe75cfk59c5akch3lmm0@4ax.com>...
On 5 Oct 2004 00:38:24 -0700, kanze@gabi-soft.fr:
charset=ISO-8859-2
Tiens, c'est quoi ce charset ?
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent
avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même
pas installé sur le système d'où je poste. (Mais j'ai l'habitude que
Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères
non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça
existe. Je précise que je n'ai rien contre la même convention mais
avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais
une majuscule sur l'avant dernière lettre. En italien, le cas n'est même
pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du
deuxième personne s'écrivent avec une majuscule en italien --
obligatoirement pour les vouvoiements, et facultativement pour le
tutoiement, et les pronoms d'objet direct ou indirect se soude après le
verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On
pourrait donc en construire une infinité d'exemples : « pensandoVi »,
« vediLe », etc.)
--
James Kanze GABI Software http://www.gabi-soft.fr
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
C'est la norme pour l'Europe de l'est. Et si mes messages apparaissent avec cet encodage, j'aimerais bien savoir pourquoi -- je ne l'ai même pas installé sur le système d'où je poste. (Mais j'ai l'habitude que Mozilla fait les siens en matière d'encodage.)
Un truc qui met des points d'interrogation à tous les caractères non-ASCII (i.e. >= 128) ?
Non.
Et est-ce que ça te g?ne en italien (? arrivederLe ?, etc.).
Non, du moins pas jusque-là, puisque je viens d'apprendre que ça existe. Je précise que je n'ai rien contre la même convention mais avec une majuscule au tout début.
En italien, arrivederLe s'écrit bien avec une minuscule au début, mais une majuscule sur l'avant dernière lettre. En italien, le cas n'est même pas exceptionnel. (Il s'agit en fait des mots composés. Les pronoms du deuxième personne s'écrivent avec une majuscule en italien -- obligatoirement pour les vouvoiements, et facultativement pour le tutoiement, et les pronoms d'objet direct ou indirect se soude après le verbe quand le verbe est à l'infinitif, l'impératif, ou le gérondif. On pourrait donc en construire une infinité d'exemples : « pensandoVi », « vediLe », etc.)
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Andre Heinen wrote in message news:...
On Sun, 3 Oct 2004 22:46:42 -0400, "Michel Michaud" wrote:
P.S. Pour ceux qui se posent la question : j'ai mis les accents intentionnellement dans mon code. Il faut partir la mode maintenant que c'est enfin possible avec un compilateur (VC++ 2005... beta !) afin de pousser les autres à respecter la norme sur ce sujet si simple il me semble...
Je ne savais pas que la norme autorisait maintenant les accents dans les identificateurs. Où puis-je me renseigner sur ce sujet? Google ne m'a pas été très utile...
En fait, la norme la toujours « autorisait », d'une certaine façon. De l'autre côté, c'est toujours défini par l'implémentation si et quoi elle accepte, en dehors des caractères de base.
Ce qui a changé, c'est que la norme a défini des possibilités à utiliser n'importe quel caractère Unicode, à condition de l'entrée sous forme d'une « universal character name », c-à-d uxxxx ou Uxxxxxxxx, où les x sont des chiffres hexadécimaux. Et si la première phase de la traduction commence toujours par « Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set[...] », la suite aujourd'hui dit que « Any character not in the basic source character set is replaced by the universal-character-name that designates that character. »
Ça veut dire que si une implémentation supporte ISO 8859-1 (ce qui n'est pas exigé), avant les universal-character-name, une implémentation aurait pu transformer un é en e. Or que maintenant, elle doit le convertir en 'u00E9'. Et qu'on accepte un bon nombre des univeral-character-name dans des identificateurs. (En gros, tous ce que l'Unicode au moment de la normalisation classifiait comme lettre -- curieusement, les chiffres ne sont pas permis.)
Ça veut dire que si tu entre « u00E9tu00E9 », tu es sûr d'avoir un indentificateur valable. Et que si tu entre « été », tu pourrais en avoir un, selon les locales installés, le locale selectionné au moment de la compilation, l'humeur du compilateur et les phases de la lune.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Andre Heinen <nospam@nospam.invalid> wrote in message
news:<h225m0196vemen7t4u7e0ahur8ecjb409p@4ax.com>...
On Sun, 3 Oct 2004 22:46:42 -0400, "Michel Michaud"
<mm@gdzid.com> wrote:
P.S. Pour ceux qui se posent la question : j'ai mis les accents
intentionnellement dans mon code. Il faut partir la mode
maintenant que c'est enfin possible avec un compilateur
(VC++ 2005... beta !) afin de pousser les autres à respecter
la norme sur ce sujet si simple il me semble...
Je ne savais pas que la norme autorisait maintenant les accents dans
les identificateurs. Où puis-je me renseigner sur ce sujet? Google ne
m'a pas été très utile...
En fait, la norme la toujours « autorisait », d'une certaine façon. De
l'autre côté, c'est toujours défini par l'implémentation si et quoi elle
accepte, en dehors des caractères de base.
Ce qui a changé, c'est que la norme a défini des possibilités à utiliser
n'importe quel caractère Unicode, à condition de l'entrée sous forme
d'une « universal character name », c-à-d uxxxx ou Uxxxxxxxx, où les x
sont des chiffres hexadécimaux. Et si la première phase de la traduction
commence toujours par « Physical source file characters are mapped, in
an implementation-defined manner, to the basic source character
set[...] », la suite aujourd'hui dit que « Any character not in the
basic source character set is replaced by the universal-character-name
that designates that character. »
Ça veut dire que si une implémentation supporte ISO 8859-1 (ce qui n'est
pas exigé), avant les universal-character-name, une implémentation
aurait pu transformer un é en e. Or que maintenant, elle doit le
convertir en 'u00E9'. Et qu'on accepte un bon nombre des
univeral-character-name dans des identificateurs. (En gros, tous ce que
l'Unicode au moment de la normalisation classifiait comme lettre --
curieusement, les chiffres ne sont pas permis.)
Ça veut dire que si tu entre « u00E9tu00E9 », tu es sûr d'avoir un
indentificateur valable. Et que si tu entre « été », tu pourrais en
avoir un, selon les locales installés, le locale selectionné au moment
de la compilation, l'humeur du compilateur et les phases de la lune.
--
James Kanze GABI Software http://www.gabi-soft.fr
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
On Sun, 3 Oct 2004 22:46:42 -0400, "Michel Michaud" wrote:
P.S. Pour ceux qui se posent la question : j'ai mis les accents intentionnellement dans mon code. Il faut partir la mode maintenant que c'est enfin possible avec un compilateur (VC++ 2005... beta !) afin de pousser les autres à respecter la norme sur ce sujet si simple il me semble...
Je ne savais pas que la norme autorisait maintenant les accents dans les identificateurs. Où puis-je me renseigner sur ce sujet? Google ne m'a pas été très utile...
En fait, la norme la toujours « autorisait », d'une certaine façon. De l'autre côté, c'est toujours défini par l'implémentation si et quoi elle accepte, en dehors des caractères de base.
Ce qui a changé, c'est que la norme a défini des possibilités à utiliser n'importe quel caractère Unicode, à condition de l'entrée sous forme d'une « universal character name », c-à-d uxxxx ou Uxxxxxxxx, où les x sont des chiffres hexadécimaux. Et si la première phase de la traduction commence toujours par « Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set[...] », la suite aujourd'hui dit que « Any character not in the basic source character set is replaced by the universal-character-name that designates that character. »
Ça veut dire que si une implémentation supporte ISO 8859-1 (ce qui n'est pas exigé), avant les universal-character-name, une implémentation aurait pu transformer un é en e. Or que maintenant, elle doit le convertir en 'u00E9'. Et qu'on accepte un bon nombre des univeral-character-name dans des identificateurs. (En gros, tous ce que l'Unicode au moment de la normalisation classifiait comme lettre -- curieusement, les chiffres ne sont pas permis.)
Ça veut dire que si tu entre « u00E9tu00E9 », tu es sûr d'avoir un indentificateur valable. Et que si tu entre « été », tu pourrais en avoir un, selon les locales installés, le locale selectionné au moment de la compilation, l'humeur du compilateur et les phases de la lune.
-- James Kanze GABI Software http://www.gabi-soft.fr 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
Arnaud Meurgues
wrote:
pas installé sur le système d'où je poste. (Mais j'ai l'habitude que Mozilla fait les siens en matière d'encodage.)
Et maintenant, il se met à poster les messages en double... ;-)
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze@gabi-soft.fr wrote:
pas installé sur le système d'où je poste. (Mais j'ai l'habitude que
Mozilla fait les siens en matière d'encodage.)
Et maintenant, il se met à poster les messages en double... ;-)
--
Arnaud
(Supprimez les geneurs pour me répondre)
ce qui est quand même plus lisible et agréable que "ete" sans accents ;-)
-- ;-)
Fabien LE LEZ
On Wed, 6 Oct 2004 00:07:29 -0400, "Michel Michaud" :
Si je me souviens bien, la standardisation proposée met les caractères sur plus de 8 bits. Et ça ne m'étonnerait pas que la plupart des compilos soient programmés sur la base 1 caractère = 8 bits.
Dans ce cas, les plate-formes auront aussi cette limitation ou alors le compilateur est inutilisable, accents ou pas.
Pourquoi ? Supposons un compilo qui n'accepte que les caractères ASCII (i.e. 7-bit), en-dehors des commentaires et éventuellement des chaînes de caractères. Avec la convention actuelle (pas d'accents ni de kanjis), vois-tu un problème à l'utiliser ? Note : les chaînes de caractères sont un cas à part : d'une part, elles sont écrites en connaissant la plate-forme d'exécution ; d'autre part, dans du code de production, elles sont rarement écrites dans le code même -- donc le compilo n'y a pas accès.
Si l'éditeur ne comprend pas les accents alors que
la plate-forme les comprend,
Ça veut dire quoi ? Je peux lire le ISO-Latin-1 sur Usenet parce que Agent se charge de le transcoder en jeu de caractères Windows au moment de l'affichage.
-- ;-)
On Wed, 6 Oct 2004 00:07:29 -0400, "Michel Michaud" <mm@gdzid.com>:
Si je me souviens bien, la standardisation proposée met les
caractères sur plus de 8 bits. Et ça ne m'étonnerait pas que la
plupart des compilos soient programmés sur la base 1 caractère = 8
bits.
Dans ce cas, les plate-formes auront aussi cette limitation ou
alors le compilateur est inutilisable, accents ou pas.
Pourquoi ?
Supposons un compilo qui n'accepte que les caractères ASCII (i.e.
7-bit), en-dehors des commentaires et éventuellement des chaînes de
caractères. Avec la convention actuelle (pas d'accents ni de kanjis),
vois-tu un problème à l'utiliser ?
Note : les chaînes de caractères sont un cas à part : d'une part,
elles sont écrites en connaissant la plate-forme d'exécution ; d'autre
part, dans du code de production, elles sont rarement écrites dans le
code même -- donc le compilo n'y a pas accès.
Si l'éditeur ne comprend pas les accents alors que
la plate-forme les comprend,
Ça veut dire quoi ?
Je peux lire le ISO-Latin-1 sur Usenet parce que Agent se charge de le
transcoder en jeu de caractères Windows au moment de l'affichage.
On Wed, 6 Oct 2004 00:07:29 -0400, "Michel Michaud" :
Si je me souviens bien, la standardisation proposée met les caractères sur plus de 8 bits. Et ça ne m'étonnerait pas que la plupart des compilos soient programmés sur la base 1 caractère = 8 bits.
Dans ce cas, les plate-formes auront aussi cette limitation ou alors le compilateur est inutilisable, accents ou pas.
Pourquoi ? Supposons un compilo qui n'accepte que les caractères ASCII (i.e. 7-bit), en-dehors des commentaires et éventuellement des chaînes de caractères. Avec la convention actuelle (pas d'accents ni de kanjis), vois-tu un problème à l'utiliser ? Note : les chaînes de caractères sont un cas à part : d'une part, elles sont écrites en connaissant la plate-forme d'exécution ; d'autre part, dans du code de production, elles sont rarement écrites dans le code même -- donc le compilo n'y a pas accès.
Si l'éditeur ne comprend pas les accents alors que
la plate-forme les comprend,
Ça veut dire quoi ? Je peux lire le ISO-Latin-1 sur Usenet parce que Agent se charge de le transcoder en jeu de caractères Windows au moment de l'affichage.
