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...