"Michel Michaud" wrote in message news:<NLb9d.31747$...
Dans le message ,
"Michel Michaud" wrote in message news:<8cK8d.11528$...
Dans le message ,
Sauf qu'il faut tout de même un tant soit peu de standardisation. Si un code qui fonctionne sur un poste ne fonctionne plus sur le poste d'à côté, avec le même compilo mais Windows en espagnol ou en grec, ça n'est pas acceptable. De même, si je ne peux plus compiler du code sous prétexte que l'auteur l'a tapé sous Linux, ça n'est pas plus acceptable.
Mais je ne vois pas pourquoi ce serait le cas.
C'est le cas. Que tu le vois ou non. J'ai déjà eu des problèmes à porter du code depuis Solaris à HP/UX. Heureusement, que dans les commentaires, parce qu'il n'y avait pas d'accents ailleurs. Mais le fait est que c'est problèmatique. Ça marche aussi longtemps que tu utilises qu'un seul système, vendu et/ou configuré pour un seul locale. Dès que tu sors de cette configuration, tu as des problèmes.
Je ne suis pas certain qu'on se comprend bien. Mon impression est que les u ont été inventés pour ça : si tu utilises des caractères qui sont acceptables (codes u acceptés selon l'annexe de la norme), tu devrais pouvoir les coder en u et les utiliser sur un autre compilateur.
Tout à fait. Mais je croyais que tu parlais du code qui contenait réelement des caractères accentués, non des u00E9 et compagnie.
En fait, les outils de développement pourraient faire ça pour toi.
Je crois que c'était un peu l'intention. Toi, tu écris été, mais ce qui se trouvait dans le fichier était u00E9tu00E9. Et évidemment, quand le fichier contenait u00E9tu00E9, l'éditeur affichait été.
Mais apparamment, mes éditeurs ne sont pas à jour. Parce qu'il ne reconnaissent pas les uxxxx.
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu lis ce fichier ailleurs en considérant que ce sont des caractères 16 bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le compiler sur un système basé sur ASCII. Voire même souvent, si tu as un fichier de Windows, avec les CRLF, et tu essaies de le compiler sous Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire. On dirait que Windows, c'est une plate-forme plus ouverte que certains Unix.)
-- 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
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<NLb9d.31747$HO1.1235943@news20.bellglobal.com>...
Dans le message d6652001.0410070145.10829627@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<8cK8d.11528$HO1.739878@news20.bellglobal.com>...
Dans le message qpp6m098jbdm3d3aton7lf14m87at57pk6@4ax.com,
Sauf qu'il faut tout de même un tant soit peu de standardisation.
Si un code qui fonctionne sur un poste ne fonctionne plus sur le
poste d'à côté, avec le même compilo mais Windows en espagnol ou
en grec, ça n'est pas acceptable. De même, si je ne peux plus
compiler du code sous prétexte que l'auteur l'a tapé sous Linux,
ça n'est pas plus acceptable.
Mais je ne vois pas pourquoi ce serait le cas.
C'est le cas. Que tu le vois ou non. J'ai déjà eu des problèmes à
porter du code depuis Solaris à HP/UX. Heureusement, que dans les
commentaires, parce qu'il n'y avait pas d'accents ailleurs. Mais le
fait est que c'est problèmatique. Ça marche aussi longtemps que tu
utilises qu'un seul système, vendu et/ou configuré pour un seul
locale. Dès que tu sors de cette configuration, tu as des problèmes.
Je ne suis pas certain qu'on se comprend bien. Mon impression est que
les u ont été inventés pour ça : si tu utilises des caractères qui
sont acceptables (codes u acceptés selon l'annexe de la norme), tu
devrais pouvoir les coder en u et les utiliser sur un autre
compilateur.
Tout à fait. Mais je croyais que tu parlais du code qui contenait
réelement des caractères accentués, non des u00E9 et compagnie.
En fait, les outils de développement pourraient faire ça pour toi.
Je crois que c'était un peu l'intention. Toi, tu écris été, mais ce qui
se trouvait dans le fichier était u00E9tu00E9. Et évidemment, quand le
fichier contenait u00E9tu00E9, l'éditeur affichait été.
Mais apparamment, mes éditeurs ne sont pas à jour. Parce qu'il ne
reconnaissent pas les uxxxx.
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu
lis ce fichier ailleurs en considérant que ce sont des caractères 16
bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le
compiler sur un système basé sur ASCII. Voire même souvent, si tu as un
fichier de Windows, avec les CRLF, et tu essaies de le compiler sous
Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire.
On dirait que Windows, c'est une plate-forme plus ouverte que certains
Unix.)
--
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
"Michel Michaud" wrote in message news:<NLb9d.31747$...
Dans le message ,
"Michel Michaud" wrote in message news:<8cK8d.11528$...
Dans le message ,
Sauf qu'il faut tout de même un tant soit peu de standardisation. Si un code qui fonctionne sur un poste ne fonctionne plus sur le poste d'à côté, avec le même compilo mais Windows en espagnol ou en grec, ça n'est pas acceptable. De même, si je ne peux plus compiler du code sous prétexte que l'auteur l'a tapé sous Linux, ça n'est pas plus acceptable.
Mais je ne vois pas pourquoi ce serait le cas.
C'est le cas. Que tu le vois ou non. J'ai déjà eu des problèmes à porter du code depuis Solaris à HP/UX. Heureusement, que dans les commentaires, parce qu'il n'y avait pas d'accents ailleurs. Mais le fait est que c'est problèmatique. Ça marche aussi longtemps que tu utilises qu'un seul système, vendu et/ou configuré pour un seul locale. Dès que tu sors de cette configuration, tu as des problèmes.
Je ne suis pas certain qu'on se comprend bien. Mon impression est que les u ont été inventés pour ça : si tu utilises des caractères qui sont acceptables (codes u acceptés selon l'annexe de la norme), tu devrais pouvoir les coder en u et les utiliser sur un autre compilateur.
Tout à fait. Mais je croyais que tu parlais du code qui contenait réelement des caractères accentués, non des u00E9 et compagnie.
En fait, les outils de développement pourraient faire ça pour toi.
Je crois que c'était un peu l'intention. Toi, tu écris été, mais ce qui se trouvait dans le fichier était u00E9tu00E9. Et évidemment, quand le fichier contenait u00E9tu00E9, l'éditeur affichait été.
Mais apparamment, mes éditeurs ne sont pas à jour. Parce qu'il ne reconnaissent pas les uxxxx.
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu lis ce fichier ailleurs en considérant que ce sont des caractères 16 bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le compiler sur un système basé sur ASCII. Voire même souvent, si tu as un fichier de Windows, avec les CRLF, et tu essaies de le compiler sous Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire. On dirait que Windows, c'est une plate-forme plus ouverte que certains Unix.)
-- 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
"Michel Michaud" wrote in message news:<4e39d.20123$...
Dans le message ,
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.
L'étape nécessaire s'appelle révision linguistique. Ça coûte cher, alors seulement les livres qui ont un bon potentiel de vente peuvent se le permettre. Rien de mystérieux :-)
Il y a plus que ça. Tu pourrais passer quelque chose que j'aurais écrit par autant de révisions linguistiques que tu veux, il ne serait jamais aussi bon que ce qu'ils ont écrit. La révision linguistique peut ratrapper des erreurs gramatiques et des choses semblables, mais il ne peut pas ajouter des détails qui manquent, ni en enlever quand il y en a de trop. Il ne peut pas changer l'ordre ni l'organisation de la présentation. Il ne peut pas ajouter des exemples où il en manque.
La révision linguistique peut rendre acceptable quelque chose qui était mauvaise. Elle ne peut pas rendre excellent quelque chose qui n'était que bon au départ.
-- 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
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<4e39d.20123$HO1.1107930@news20.bellglobal.com>...
Dans le message d6652001.0410060110.4086b534@posting.google.com,
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.
L'étape nécessaire s'appelle révision linguistique. Ça coûte cher,
alors seulement les livres qui ont un bon potentiel de vente peuvent
se le permettre. Rien de mystérieux :-)
Il y a plus que ça. Tu pourrais passer quelque chose que j'aurais écrit
par autant de révisions linguistiques que tu veux, il ne serait jamais
aussi bon que ce qu'ils ont écrit. La révision linguistique peut
ratrapper des erreurs gramatiques et des choses semblables, mais il ne
peut pas ajouter des détails qui manquent, ni en enlever quand il y en a
de trop. Il ne peut pas changer l'ordre ni l'organisation de la
présentation. Il ne peut pas ajouter des exemples où il en manque.
La révision linguistique peut rendre acceptable quelque chose qui était
mauvaise. Elle ne peut pas rendre excellent quelque chose qui n'était
que bon au départ.
--
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
"Michel Michaud" wrote in message news:<4e39d.20123$...
Dans le message ,
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.
L'étape nécessaire s'appelle révision linguistique. Ça coûte cher, alors seulement les livres qui ont un bon potentiel de vente peuvent se le permettre. Rien de mystérieux :-)
Il y a plus que ça. Tu pourrais passer quelque chose que j'aurais écrit par autant de révisions linguistiques que tu veux, il ne serait jamais aussi bon que ce qu'ils ont écrit. La révision linguistique peut ratrapper des erreurs gramatiques et des choses semblables, mais il ne peut pas ajouter des détails qui manquent, ni en enlever quand il y en a de trop. Il ne peut pas changer l'ordre ni l'organisation de la présentation. Il ne peut pas ajouter des exemples où il en manque.
La révision linguistique peut rendre acceptable quelque chose qui était mauvaise. Elle ne peut pas rendre excellent quelque chose qui n'était que bon au départ.
-- 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
Loïc Joly wrote:
La solution en python est d'indiquer au tout début du fichier l'encoding de ce fichier. Ca me semble être une solution applicable en C++, non ?
Tout-à-fait. C'est ce que je suggérais plus haut. Mais mon point de vue est que la norme actuelle ne peut demander de comprendre n'importe quel couple charset/encoding puisqu'elle ne définit pas de manière de le spécifier.
Mais sinon, moi, je suis pour un moyen de spécifier charset et encoding dans un fichier source C++.
-- Arnaud (Supprimez les geneurs pour me répondre)
Loïc Joly wrote:
La solution en python est d'indiquer au tout début du fichier l'encoding
de ce fichier. Ca me semble être une solution applicable en C++, non ?
Tout-à-fait. C'est ce que je suggérais plus haut.
Mais mon point de vue est que la norme actuelle ne peut demander de
comprendre n'importe quel couple charset/encoding puisqu'elle ne définit
pas de manière de le spécifier.
Mais sinon, moi, je suis pour un moyen de spécifier charset et encoding
dans un fichier source C++.
--
Arnaud
(Supprimez les geneurs pour me répondre)
La solution en python est d'indiquer au tout début du fichier l'encoding de ce fichier. Ca me semble être une solution applicable en C++, non ?
Tout-à-fait. C'est ce que je suggérais plus haut. Mais mon point de vue est que la norme actuelle ne peut demander de comprendre n'importe quel couple charset/encoding puisqu'elle ne définit pas de manière de le spécifier.
Mais sinon, moi, je suis pour un moyen de spécifier charset et encoding dans un fichier source C++.
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
wrote:
Applicable, mais non appliqué. Je verrais bien un espèce de #pragma codeset iso_8859_1 par exemple.
Je suis pour.
Une autre possibilité que j'ai considéré, c'est un fichier de configuration dans le répertoire, du genre .codeset. Si ce fichier est présent, le compilateur lirait tous les fichiers du répertoire avec cet encodage.
Là, je suis contre car cette solution ne permet pas, telle que tu l'énonces, d'avoir plusieurs encodages dans le même répertoire. Si on affine en permettant que le fichier .codeset puisse: - spécifier un codeset par défaut pour tous les fichiers - spécifier un codeset par fichier remplaçant le défaut alors ça devient une solution que je trouve acceptable.
(L'avantage, c'est qu'on peut le faire après le coup, sans modifier les fichiers sources, et que les compilateurs qui ne connaissent pas l'astuce ne verrait rien.)
Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze@gabi-soft.fr wrote:
Applicable, mais non appliqué. Je verrais bien un espèce de
#pragma codeset iso_8859_1
par exemple.
Je suis pour.
Une autre possibilité que j'ai considéré, c'est un fichier de
configuration dans le répertoire, du genre .codeset. Si ce fichier est
présent, le compilateur lirait tous les fichiers du répertoire avec cet
encodage.
Là, je suis contre car cette solution ne permet pas, telle que tu
l'énonces, d'avoir plusieurs encodages dans le même répertoire.
Si on affine en permettant que le fichier .codeset puisse:
- spécifier un codeset par défaut pour tous les fichiers
- spécifier un codeset par fichier remplaçant le défaut
alors ça devient une solution que je trouve acceptable.
(L'avantage, c'est qu'on peut le faire après le coup, sans
modifier les fichiers sources, et que les compilateurs qui ne
connaissent pas l'astuce ne verrait rien.)
Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Applicable, mais non appliqué. Je verrais bien un espèce de #pragma codeset iso_8859_1 par exemple.
Je suis pour.
Une autre possibilité que j'ai considéré, c'est un fichier de configuration dans le répertoire, du genre .codeset. Si ce fichier est présent, le compilateur lirait tous les fichiers du répertoire avec cet encodage.
Là, je suis contre car cette solution ne permet pas, telle que tu l'énonces, d'avoir plusieurs encodages dans le même répertoire. Si on affine en permettant que le fichier .codeset puisse: - spécifier un codeset par défaut pour tous les fichiers - spécifier un codeset par fichier remplaçant le défaut alors ça devient une solution que je trouve acceptable.
(L'avantage, c'est qu'on peut le faire après le coup, sans modifier les fichiers sources, et que les compilateurs qui ne connaissent pas l'astuce ne verrait rien.)
Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
-- Arnaud (Supprimez les geneurs pour me répondre)
Gabriel Dos Reis
Arnaud Meurgues writes:
| wrote: | | > Applicable, mais non appliqué. Je verrais bien un espèce de | > #pragma codeset iso_8859_1 | > par exemple. | | Je suis pour.
Je suis contre tout ce qui commence avec #pragma ou variantes.
[...]
| Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
| kanze@gabi-soft.fr wrote:
|
| > Applicable, mais non appliqué. Je verrais bien un espèce de
| > #pragma codeset iso_8859_1
| > par exemple.
|
| Je suis pour.
Je suis contre tout ce qui commence avec #pragma ou variantes.
[...]
| Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
| wrote: | | > Applicable, mais non appliqué. Je verrais bien un espèce de | > #pragma codeset iso_8859_1 | > par exemple. | | Je suis pour.
Je suis contre tout ce qui commence avec #pragma ou variantes.
[...]
| Avec un pragma, ça n'embête pas non plus un compilo qui ne le gère pas.
Si. Il ignore le pragma et se plaint après.
-- Gaby
Falk Tannhäuser
wrote:
Fabien LE LEZ wrote in message
Du coup, tu n'as pas besoin que le compilo comprenne les caractères non-ASCII, il suffit de modifier ton code en entrée. Par exemple :
a-zA-Z restent tels quels _ devient _005F é devient _00E9 à devient _00E0 rho minuscule devient _03C1
Et zou, tu tapes les caractères que tu veux, tu passes la moulinette, et le compilo n'y voit que du feu. Reste à passer les messages d'erreurs à la moulinette inverse, et le tour est joué.
Qu'est-ce qui se passe avec :
void f() { int été ; int _00E9t_00E9 ; }
Ça deviendra
void f() { int _00E9t_00E9; int _005F00E9t_005F00E9; } si j'ai bien compris.
Je ne suis pas sûr que cela ne pose pas de problèmes d'interopérabi lité ailleurs, surtout au niveau de compatibilité avec le C ... (Combien de compilateurs C++ bronchent aujourd'hui sur char *pc = std::strchr("Hello", 'o'); ou mettent toupper / tolower dans le namespace std ?)
Falk
kanze@gabi-soft.fr wrote:
Fabien LE LEZ <gramster@gramster.com> wrote in message
Du coup, tu n'as pas besoin que le compilo comprenne les caractères
non-ASCII, il suffit de modifier ton code en entrée. Par exemple :
a-zA-Z restent tels quels
_ devient _005F
é devient _00E9
à devient _00E0
rho minuscule devient _03C1
Et zou, tu tapes les caractères que tu veux, tu passes la moulinette,
et le compilo n'y voit que du feu. Reste à passer les messages
d'erreurs à la moulinette inverse, et le tour est joué.
Qu'est-ce qui se passe avec :
void
f()
{
int été ;
int _00E9t_00E9 ;
}
Ça deviendra
void f()
{
int _00E9t_00E9;
int _005F00E9t_005F00E9;
}
si j'ai bien compris.
Je ne suis pas sûr que cela ne pose pas de problèmes d'interopérabi lité
ailleurs, surtout au niveau de compatibilité avec le C ...
(Combien de compilateurs C++ bronchent aujourd'hui sur
char *pc = std::strchr("Hello", 'o');
ou mettent toupper / tolower dans le namespace std ?)
Du coup, tu n'as pas besoin que le compilo comprenne les caractères non-ASCII, il suffit de modifier ton code en entrée. Par exemple :
a-zA-Z restent tels quels _ devient _005F é devient _00E9 à devient _00E0 rho minuscule devient _03C1
Et zou, tu tapes les caractères que tu veux, tu passes la moulinette, et le compilo n'y voit que du feu. Reste à passer les messages d'erreurs à la moulinette inverse, et le tour est joué.
Qu'est-ce qui se passe avec :
void f() { int été ; int _00E9t_00E9 ; }
Ça deviendra
void f() { int _00E9t_00E9; int _005F00E9t_005F00E9; } si j'ai bien compris.
Je ne suis pas sûr que cela ne pose pas de problèmes d'interopérabi lité ailleurs, surtout au niveau de compatibilité avec le C ... (Combien de compilateurs C++ bronchent aujourd'hui sur char *pc = std::strchr("Hello", 'o'); ou mettent toupper / tolower dans le namespace std ?)
Falk
Mickael Pointier
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu lis ce fichier ailleurs en considérant que ce sont des caractères 16 bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le compiler sur un système basé sur ASCII. Voire même souvent, si tu as un fichier de Windows, avec les CRLF, et tu essaies de le compiler sous Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire. On dirait que Windows, c'est une plate-forme plus ouverte que certains Unix.)
J'ai constaté la même chose chez moi.
Je bosse avec des linuxiens, qui ont un mal fou à digérer les retours chariot façon windows, alors que de mon coté mes éditeurs et compilateurs avalent les deux formats sans aucun problème.
Il ne reste plus guère que "notepad" pour ne pas supporter les retour chariot façon unix.
Mike
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu
lis ce fichier ailleurs en considérant que ce sont des caractères 16
bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le
compiler sur un système basé sur ASCII. Voire même souvent, si tu as un
fichier de Windows, avec les CRLF, et tu essaies de le compiler sous
Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire.
On dirait que Windows, c'est une plate-forme plus ouverte que certains
Unix.)
J'ai constaté la même chose chez moi.
Je bosse avec des linuxiens, qui ont un mal fou à digérer les retours
chariot façon windows, alors que de mon coté mes éditeurs et compilateurs
avalent les deux formats sans aucun problème.
Il ne reste plus guère que "notepad" pour ne pas supporter les retour
chariot façon unix.
Accents ou pas, si tu as un source codé en caractères 8 bits et que tu lis ce fichier ailleurs en considérant que ce sont des caractères 16 bits, il y aura un problème.
De même que si tu as un source codé en EBCDIC, et tu essaies à le compiler sur un système basé sur ASCII. Voire même souvent, si tu as un fichier de Windows, avec les CRLF, et tu essaies de le compiler sous Unix. (Curieusement, je n'ai jamais eu de problèmes en sens contraire. On dirait que Windows, c'est une plate-forme plus ouverte que certains Unix.)
J'ai constaté la même chose chez moi.
Je bosse avec des linuxiens, qui ont un mal fou à digérer les retours chariot façon windows, alors que de mon coté mes éditeurs et compilateurs avalent les deux formats sans aucun problème.
Il ne reste plus guère que "notepad" pour ne pas supporter les retour chariot façon unix.
Mike
Mickael Pointier
[...] En fait, il y a pas moins de trois encodages indépendamment courants à la fois :
[...] - Il y a celui qui sert dans la logique à l'intérieur des programmes, pour déterminer si un caractère donné est un blanc ou un chiffre, par exemple. Ici, ça dépend du programme -- beaucoup de programmes utilise la même stratégie que le système, en limitant les caractères qui l'intéresse à un petit ensemble dont l'encodage ne varient pas. Mais si le programme va plus loin, cet encodage dépend du locale.
Et sur les systèmes dont je me sers, le locale par défaut dépend des variables d'environement, qui sont propre à chaque utilisateur. Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache qui a écrit le fichier. Et encore -- s'il détermine que c'est l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il doit encore régarder quel shell j'utilise (dans /etc/passwd), et en fonction du shell, lire le fichier d'initialisation qui convient. Sauf qu'il y a deux problèmes de taille avec cette politique :
[...]
D'ailleur, à titre d'anecdote, il y à eu récement un problème avec une des beta-versions de "whidbey" (le petit nom de Visual Studio 2005), à propos de la gestion des locales dans le compilateur.
Un certain nombre de personnes se sont trouvés à ne plus pouvoir de compiler les sources C++ contenant des valeurs littérales en virgule flotante:
float pi=3.14159f;
Erreur :)
La raison est que le compilateur sur ces machines (françaises, et allemandes en autre), se basait sur la locale qui était configurée pour utiliser la virgule en temps que délimitateur décimal.
Super...
Donc obligé de changer la locale du système, parce que bien évidement le compilateur n'acceptait pas non plus correctement que l'on tappe "3,14159f" à la place :-)
Mike
[...]
En fait, il y a pas moins de trois encodages indépendamment courants à
la fois :
[...]
- Il y a celui qui sert dans la logique à l'intérieur des programmes,
pour déterminer si un caractère donné est un blanc ou un chiffre,
par exemple. Ici, ça dépend du programme -- beaucoup de programmes
utilise la même stratégie que le système, en limitant les caractères
qui l'intéresse à un petit ensemble dont l'encodage ne varient pas.
Mais si le programme va plus loin, cet encodage dépend du locale.
Et sur les systèmes dont je me sers, le locale par défaut dépend des
variables d'environement, qui sont propre à chaque utilisateur.
Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache
qui a écrit le fichier. Et encore -- s'il détermine que c'est
l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il
doit encore régarder quel shell j'utilise (dans /etc/passwd), et en
fonction du shell, lire le fichier d'initialisation qui convient.
Sauf qu'il y a deux problèmes de taille avec cette politique :
[...]
D'ailleur, à titre d'anecdote, il y à eu récement un problème avec une des
beta-versions de "whidbey" (le petit nom de Visual Studio 2005), à propos de
la gestion des locales dans le compilateur.
Un certain nombre de personnes se sont trouvés à ne plus pouvoir de compiler
les sources C++ contenant des valeurs littérales en virgule flotante:
float pi=3.14159f;
Erreur :)
La raison est que le compilateur sur ces machines (françaises, et allemandes
en autre), se basait sur la locale qui était configurée pour utiliser la
virgule en temps que délimitateur décimal.
Super...
Donc obligé de changer la locale du système, parce que bien évidement le
compilateur n'acceptait pas non plus correctement que l'on tappe "3,14159f"
à la place :-)
[...] En fait, il y a pas moins de trois encodages indépendamment courants à la fois :
[...] - Il y a celui qui sert dans la logique à l'intérieur des programmes, pour déterminer si un caractère donné est un blanc ou un chiffre, par exemple. Ici, ça dépend du programme -- beaucoup de programmes utilise la même stratégie que le système, en limitant les caractères qui l'intéresse à un petit ensemble dont l'encodage ne varient pas. Mais si le programme va plus loin, cet encodage dépend du locale.
Et sur les systèmes dont je me sers, le locale par défaut dépend des variables d'environement, qui sont propre à chaque utilisateur. Donc, si le compilateur veut savoir l'encodage, il faut qu'il sache qui a écrit le fichier. Et encore -- s'il détermine que c'est l'utilisateur jakan (c'est mon identificateur ici) qui l'a écrit, il doit encore régarder quel shell j'utilise (dans /etc/passwd), et en fonction du shell, lire le fichier d'initialisation qui convient. Sauf qu'il y a deux problèmes de taille avec cette politique :
[...]
D'ailleur, à titre d'anecdote, il y à eu récement un problème avec une des beta-versions de "whidbey" (le petit nom de Visual Studio 2005), à propos de la gestion des locales dans le compilateur.
Un certain nombre de personnes se sont trouvés à ne plus pouvoir de compiler les sources C++ contenant des valeurs littérales en virgule flotante:
float pi=3.14159f;
Erreur :)
La raison est que le compilateur sur ces machines (françaises, et allemandes en autre), se basait sur la locale qui était configurée pour utiliser la virgule en temps que délimitateur décimal.
Super...
Donc obligé de changer la locale du système, parce que bien évidement le compilateur n'acceptait pas non plus correctement que l'on tappe "3,14159f" à la place :-)
Mike
Jean-Marc Bourguet
writes:
(Note que plus un projet est grand, plus il y a des chances qu'il soit international, et donc, plus il y a de chances que la langue du projet soit l'anglais, où le problème des caractères accentués ne se pose pas.)
This seems a somewhat naïve opinion :-)
Yours,
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze@gabi-soft.fr writes:
(Note que plus un projet est grand, plus il y a des chances qu'il
soit international, et donc, plus il y a de chances que la langue du
projet soit l'anglais, où le problème des caractères accentués ne se
pose pas.)
This seems a somewhat naïve opinion :-)
Yours,
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
(Note que plus un projet est grand, plus il y a des chances qu'il soit international, et donc, plus il y a de chances que la langue du projet soit l'anglais, où le problème des caractères accentués ne se pose pas.)
This seems a somewhat naïve opinion :-)
Yours,
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
drkm
"Michel Michaud" writes:
Dans le message ,
"Michel Michaud" writes:
Oui, mais les outils permettant de transférer les fichiers n'ont pas de problèmes avec mes accents...
Et avec ceux des autres ?
(je suis sérieux)
?
Que ces programmes n'aient pas de problème avec tes accents, ce n'est pas très intéressant. Il me semble que c'est plutôt le nombre incroyablement élevé d'encodages différents qui constitue un problème.
Mais je ne suis pas spécialiste en ces questions.
--drkm
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message wkr7ob9wii.fsf@fgeorges.org,
"Michel Michaud" <mm@gdzid.com> writes:
Oui, mais les outils permettant de transférer les fichiers n'ont
pas de problèmes avec mes accents...
Et avec ceux des autres ?
(je suis sérieux)
?
Que ces programmes n'aient pas de problème avec tes accents, ce
n'est pas très intéressant. Il me semble que c'est plutôt le nombre
incroyablement élevé d'encodages différents qui constitue un problème.
Oui, mais les outils permettant de transférer les fichiers n'ont pas de problèmes avec mes accents...
Et avec ceux des autres ?
(je suis sérieux)
?
Que ces programmes n'aient pas de problème avec tes accents, ce n'est pas très intéressant. Il me semble que c'est plutôt le nombre incroyablement élevé d'encodages différents qui constitue un problème.
