Discussion :

[JolyLoic]

[edit]Cette branche est issue d'une digression à partir de la discussion http://www.developpez.net/forums/d67...e/#post3976639[/edit]

Tu sais qu'il m'arrive de mettre des des é,è,à,ê dans mes noms de variable, de fonction, de classes...

[ram-0000]

Tu sais qu'il m'arrive de mettre des des é,è,à,ê dans mes noms de variable, de fonction, de classes...

C'est autorisé, je croyais que c'était uniquement [a-z][A-Z][0-9] et '_' ?

[JolyLoic]

C'est autorisé, mais non garanti :

1. Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing new-line characters for end-of-line indicators) if necessary. The set of physical source file characters accepted is implementation-defined. Trigraph sequences (2.3) are replaced by corresponding single-character internal representations. Any source file character not in the basic source character set (2.2) is replaced by the universal-character-name that designates that character. (An implementation may use any internal encoding, so long as an actual extended character encountered in the source file, and the same extended character expressed in the source file as a universal-character-name (i.e. using the \uXXXX notation), are handled equivalently.)

Et :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
identifier:
  identifier-nondigit
  identifier identifier-nondigit
  identifier digit
identifier-nondigit:
  nondigit
  universal-character-name
  other implementation-defined characters

J'avoue que j'hésiterais à l'utiliser pour du code de production ou portable (par exemple ma version de gcc, contrairement à Visual C++ ne les accepte pas), mais quand je dois écrire du code en français (code de démo ou de test, souvent), je préfère l'écrire en français correct, sinon c'est incompréhensible (exemple : mange et mangé sont deux noms de fonctions possibles pour un jeu de dames, mais ont des sens totalement opposés).

[ram-0000]

A mon avis, sur ce coup, les normalisateurs auraient mieux fait de s'abstenir, c'est le meilleur moyen de rajouter un comportement indéfini (cela compile ici mais pas là et je comprend pas pourquoi).

Pour moi (mais cela n'engage que moi), l'ancienne règle ([a-z][A-Z][0-9] et '_') me va très bien, pas besoin de rajouter des accents et autres trigraphes.

[JolyLoic]

Et donc tu interdis à des gens d'écrire du code dans leur langue natale ? Je pense certes qu'il est souvent judicieux de coder en anglais, mais je pense qu'il serait trop limitatif d'opposer un obstacle supplémentaire à un chinois, un indien, un coréen, un klingon (encore que pour eux...) ou un français qui veut écrire un programme.

Ou alors, si on veut imposer une langue d'écriture de code, autant que ce soit le chinois, c'est quand même la langue maternelle la plus courante.

Et ça ne rajoute pas vraiment de comportement indéfini par rapport à un programme qui utiliserait uniquement de tels caractères dans des constantes chaînes, ou même simplement dans des commentaires. Le comportement indéfini est dans la première phase de translation, par laquelle passent en effet ces éléments. A l'issue de cette phase, tous ces caractères sont (philosophiquement du moins) remplacés par des UNC. Et la norme oblige à accepter les UNC représentant des lettres dans les noms d'identificateurs.

Telle que je la lis, un compilateur qui accepte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cout << "Salut à vous";

Mais pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int salut_à_vous;

N'est pas conforme.

Quant aux trigraphs, pas le choix, ils étaient obligatoires pour gérer des environnements au jeu de caractère encore plus limité que l'ascii. Et ils ne sont pas autorisés dans les identificateurs.

[LittleWhite]

Marche pas sur gcc , du moins...

[droggo]

Hea,

Je ne suis pas contre, mais alors commençons par unifier tous les encodages sur tous les systèmes (du boulot en vue, hein ?).

[Médinoc]

Un bon pas en avant dans ce sens serait que Windows supporte pleinement l'UTF-8. Ce qui, d'après leurs bloggeurs, implique de réécrire et re-tester toutes les fonctions de traitement de chaînes qui n'ont pas été pensées pour gérer des caractères de plus de deux chars. Et surtout, vérifier que le nouveau comportement ne "casse" aucune application existante.

Par contre, ce qui ne ferait pas de mal à Windows, ce serait un meilleur support de l'unicode dans les consoles. Pour l'instant, seul un appel à WriteConsoleW() écrit les accents correctement (et ne marche pas si la sortie est redirigée vers un fichier), alors qu'un wprintf() foire.

Une fois l'Unicode mieux supporté sur les principaux OS, on pourra envisager d'accroitre leur support par les compilateurs...

[JolyLoic]

Ou que linux supporte pleinement l'UCS-2... Ce qui implique probablement de réécrire et re-tester toutes les fonctions de chaînes de caractères qui n'ont pas été pensées pour gérer des wchar_t.

Pour ce qui est des accents dans la console, je n'ai aucun problème à écrire dedans une fois la bonne locale mise en place dans mon programme à partir de Visual Studio. Ca ne marchait pas avec gcc, la dernière fois que j'ai testé, mais je soupçonne plus une mauvaise gestion de ce dernier sous windows.

Par contre, il est vrai qu'écrire des caractères ne faisant pas partie du jeu de caractères de langue d'installation pose plus de problèmes. Je n'arrive pas par exemple à afficher de caractères japonais dans une console sous mon windows installé en français (Il faudrait que j'essaye mon programme sous une machine japonaise).

[Médinoc]

Déjà d'après ce que j'ai vu, pour écrire correctement sur la console, il faut employer une police true type (comme Lucida Console). Sinon, même en unicode, les caractères sont convertis en caractères le plus proche:
http://www.developpez.net/forums/d67...a/#post3956391

[JolyLoic]

J'ai une console avec la police par défaut, non true type, et pas lucida, et le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#include <iostream>
 
using namespace std;
 
int main()
{
	locale::global(locale(""));
	cout << L"éàù" << endl;
}

affiche bien les accents.

[Médinoc]

Merci pour le coup de la locale. Y a-t-il un équivalent en C ?

Les polices raster supportent apparemment tous les caractères de la page de code OEM sélectionnée, ce qui fait que les accents passent. Des caractères plus exotiques comme le TM, par contre...

[camboui]

J'ai des collègues chinois, russes, japonais, indiens, grecs, etc.
Je nous vois mal partager du code si chacun écrit dans sa langue avec son écriture...
Non mais, vous imaginez des balises xml ou des url en katana ou cyrilic ?
Je suis pour la diversité culturelle, mais aussi pour l'unification des "structures" de communication.
Le wwscii me va très bien

[JolyLoic]

Il s'agit là d'un problème différent je pense. Dans un contexte international, il me semble en effet une très bonne chose de choisir une langue commune, et l'anglais est souvent un bon choix de langue commune. Et si on code en anglais, on n'aura le plus souvent pas besoin d'accents dans le code source pour écrire correctement les identificateurs.

Maintenant, dans un contexte non international (exemple : Un cours donné en français, du code posté ici, du code franco-français car traitant un problème qui par sa nature même n'est pas exportable, comme un calcul d'impôts...), où le choix a été fait d'écrire dans une langue qui se trouve avoir des accents ou utiliser des "alphabets" non compatibles ascii, il me semble important de respecter les langues en question, et de ne pas imposer une transcription pseudo phonétique de cette langue sur un alphabet ascii.

J'ai du de nombreuses fois lire du code écrit en "pseudo-français-désaccentué", et en particulier, dans ce code, quand on voit un 'e', on ne sait pas si l'utilisateur a voulu écrire 'e', 'é', 'è', 'ê', 'ë'. Et ça peut souvent mener à la confusion, par exemple entre verbe au présent, ou participe passé (passif ?), ce qui peut avoir des significations opposées.

Donc, je ne préconise pas de coder avec des accents, mais de choisir la langue de codage (souvent l'anglais), et de coder en écrivant correctement dans cette langue (et je regrette que certains compilateurs ne me laissent pas le faire).

Et en tout cas, par rapport à la question initiale, un outil qui ne prendrait pas en compte les mêmes caractères que les compilateurs avec lesquels il est sensé marcher me semblerait avoir un gros problème.

[3DArchi]

Il s'agit là d'un problème différent je pense. Dans un contexte international, il me semble en effet une très bonne chose de choisir une langue commune, et l'anglais est souvent un bon choix de langue commune. Et si on code en anglais, on n'aura le plus souvent pas besoin d'accents dans le code source pour écrire correctement les identificateurs.

Effectivement, c'est le premier critère pour la langue de codage : programme international ou pas !

je regrette que certains compilateurs ne me laissent pas le faire.

Dans les boîtes où j'ai eu l'occasion de bosser, en général, les règles de codage imposent de ne pas utiliser de tels caractères. L'objectif lié est d'avoir du code compilable avec n'importe quel compilateur. Vœux souvent pieux puisque souvent des extensions non standard peuvent se retrouver ensuite dans le code...

[Noxen]

Pour ce qui est des accents dans la console, je n'ai aucun problème à écrire dedans une fois la bonne locale mise en place dans mon programme à partir de Visual Studio.

Là ça me rend curieux. Tu peux apporter des précisions (ou me rediriger vers un tuto, ça me va aussi) ?

[JolyLoic]

As tu essayé le code dans http://www.developpez.net/forums/d68...e/#post3978551 ? Quel genre de précision souhaites-tu ?

[Jean-Marc.Bourguet]

Merci pour le coup de la locale. Y a-t-il un équivalent en C ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

setlocale(LC_ALL, "");

[Noxen]

Plutôt que de réutiliser ce bout de code sans réfléchir j'aurais voulu comprendre ce qu'il y a derrière. Qu'est-ce-que cette classe locale ? Dans quel espace de nom ou dans quel fichier est-elle décrite (apparement iostream et std suffisent) ? Que fait locale("") ? Pourquoi des "", est-ce-que ça référence le langage régional paramétré sur la machine ?

Je n'ai pas encore trouvé de référence sur le sujet dans la FAQ ni à priori dans les tutoriels (mais je n'ai pas vraiment été exhaustif dans mes recherches, donc j'ai pu rater des trucs).

[Jean-Marc.Bourguet]

Plutôt que de réutiliser ce bout de code sans réfléchir j'aurais voulu comprendre ce qu'il y a derrière. Qu'est-ce-que cette classe locale ?

La classe qui gere les informations de localisation.

Dans quel espace de nom ou dans quel fichier est-elle décrite (apparement iostream et std suffisent) ?

<locale> et std::

Que fait locale("") ? Pourquoi des "", est-ce-que ça référence le langage régional paramétré sur la machine ?

Ca construit une classe qui a les parametres de localisation correspondant a l'environnement. (Je ne connais pas Windows, mais sous Unix il n'y a rien de propre a la machine, c'est des variables d'environnements qui gerent cela; et ca m'arrive regulierement de les changer pour un process ou l'autre).

Je n'ai pas encore trouvé de référence sur le sujet dans la FAQ ni à priori dans les tutoriels (mais je n'ai pas vraiment été exhaustif dans mes recherches, donc j'ai pu rater des trucs).

http://www.research.att.com/~bs/3rd_loc0.html