Dans l'article <43ae6bd3$0$11351$, Richard Delorme écrit:
D'après cet extrait, on peut mettre les caractères que l'on veut dans les commentaires.
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ? L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
-- Richard
Dans l'article <43ae6bd3$0$11351$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
D'après cet extrait, on peut mettre les caractères que l'on veut dans
les commentaires.
À condition qu'ils fassent partie du jeu de caractères ou qu'ils
soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en
définissant plusieurs ?
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic
source character set", sauf les commentaires, les chaines, etc. Donc les
commentaires peuvent être écrit avec l'"extended source character set",
que la norme ne spécifie pas, mais dit qu'il s'agit de caractères
"locale-specific", comme les caractères accentués du français, par
exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Dans l'article <43ae6bd3$0$11351$, Richard Delorme écrit:
D'après cet extrait, on peut mettre les caractères que l'on veut dans les commentaires.
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ? L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
-- Richard
loufoque
3 Both the basic source and basic execution character sets shall have the following members: the 26 uppercase letters of the Latin alphabet A B C D E F G H I J K L M N O P Q R S T U V W X Y Z the 26 lowercase letters of the Latin alphabet a b c d e f g h i j k l m n o p q r s t u v w x y z the 10 decimal digits 0 1 2 3 4 5 6 7 8 9 the following 29 graphic characters ! " # % & ' ( ) * + , - . / : ; < = > ? [ ] ^ _ { | } ~ the space character, and control characters representing horizontal tab, vertical tab, and form feed.
Ce n'est pas parce que le charset doit contenir ces caractères qu'il ne doit contenir que ceux-ci.
Cela ne change en rien ce que j'ai dit. Ça ne fait qu'ajouter le fait qu'il doive contenir tous ces caractères que j'ai omis.
3 Both the basic source and basic execution character sets shall have
the following
members: the 26 uppercase letters of the Latin alphabet
A B C D E F G H I J K L M
N O P Q R S T U V W X Y Z
the 26 lowercase letters of the Latin alphabet
a b c d e f g h i j k l m
n o p q r s t u v w x y z
the 10 decimal digits
0 1 2 3 4 5 6 7 8 9
the following 29 graphic characters
! " # % & ' ( ) * + , - . / :
; < = > ? [ ] ^ _ { | } ~
the space character, and control characters representing horizontal tab,
vertical tab, and
form feed.
Ce n'est pas parce que le charset doit contenir ces caractères qu'il ne
doit contenir que ceux-ci.
Cela ne change en rien ce que j'ai dit. Ça ne fait qu'ajouter le fait
qu'il doive contenir tous ces caractères que j'ai omis.
3 Both the basic source and basic execution character sets shall have the following members: the 26 uppercase letters of the Latin alphabet A B C D E F G H I J K L M N O P Q R S T U V W X Y Z the 26 lowercase letters of the Latin alphabet a b c d e f g h i j k l m n o p q r s t u v w x y z the 10 decimal digits 0 1 2 3 4 5 6 7 8 9 the following 29 graphic characters ! " # % & ' ( ) * + , - . / : ; < = > ? [ ] ^ _ { | } ~ the space character, and control characters representing horizontal tab, vertical tab, and form feed.
Ce n'est pas parce que le charset doit contenir ces caractères qu'il ne doit contenir que ceux-ci.
Cela ne change en rien ce que j'ai dit. Ça ne fait qu'ajouter le fait qu'il doive contenir tous ces caractères que j'ai omis.
loufoque
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ? L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
L'implémentation est libre de choisir ce qu'elle veut pour chacun des jeux de caractères.
Qu'ils fassent parties de quel jeu de caractères, la norme en
définissant plusieurs ?
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic
source character set", sauf les commentaires, les chaines, etc. Donc les
commentaires peuvent être écrit avec l'"extended source character set",
que la norme ne spécifie pas, mais dit qu'il s'agit de caractères
"locale-specific", comme les caractères accentués du français, par
exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
L'implémentation est libre de choisir ce qu'elle veut pour chacun des
jeux de caractères.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ? L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
L'implémentation est libre de choisir ce qu'elle veut pour chacun des jeux de caractères.
Vincent Lefevre
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Dans l'article <43ae94d2$0$11351$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils
soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en
définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic
source character set", sauf les commentaires, les chaines, etc. Donc les
commentaires peuvent être écrit avec l'"extended source character set",
que la norme ne spécifie pas, mais dit qu'il s'agit de caractères
"locale-specific", comme les caractères accentués du français, par
exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une
implémentation peut très bien refuser tout caractère accentué.
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Post supprimé (erreur d'aiguillage. Facile de se tromper avec ThunderBird)
-- A+
Emmanuel Delahaye
Richard Delorme
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code source codé en EBDIC, je ne peux pas le compiler sur mon implémentation qui n'accepte que de l'ANSI.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Pas s'il est dans les commentaires.
-- Richard
Dans l'article <43ae94d2$0$11351$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils
soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en
définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code
source codé en EBDIC, je ne peux pas le compiler sur mon implémentation
qui n'accepte que de l'ANSI.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic
source character set", sauf les commentaires, les chaines, etc. Donc les
commentaires peuvent être écrit avec l'"extended source character set",
que la norme ne spécifie pas, mais dit qu'il s'agit de caractères
"locale-specific", comme les caractères accentués du français, par
exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une
implémentation peut très bien refuser tout caractère accentué.
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code source codé en EBDIC, je ne peux pas le compiler sur mon implémentation qui n'accepte que de l'ANSI.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Pas s'il est dans les commentaires.
-- Richard
Richard Delorme
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code source codé en EBDIC, je ne peux pas le compiler sur mon implémentation qui n'accepte que de l'ASCII.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Pas s'il est dans les commentaires.
-- Richard
Dans l'article <43ae94d2$0$11351$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils
soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en
définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code
source codé en EBDIC, je ne peux pas le compiler sur mon implémentation
qui n'accepte que de l'ASCII.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic
source character set", sauf les commentaires, les chaines, etc. Donc les
commentaires peuvent être écrit avec l'"extended source character set",
que la norme ne spécifie pas, mais dit qu'il s'agit de caractères
"locale-specific", comme les caractères accentués du français, par
exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une
implémentation peut très bien refuser tout caractère accentué.
Dans l'article <43ae94d2$0$11351$, Richard Delorme écrit:
À condition qu'ils fassent partie du jeu de caractères ou qu'ils soient traduits sans erreur.
Qu'ils fassent parties de quel jeu de caractères, la norme en définissant plusieurs ?
Celui accepté par l'implémentation, suivant le contexte.
Alors le problème se pose pour tous les caractères. Si j'ai un code source codé en EBDIC, je ne peux pas le compiler sur mon implémentation qui n'accepte que de l'ASCII.
L'extrait que j'ai cité dit que le source doit être écrit avec le "basic source character set", sauf les commentaires, les chaines, etc. Donc les commentaires peuvent être écrit avec l'"extended source character set", que la norme ne spécifie pas, mais dit qu'il s'agit de caractères "locale-specific", comme les caractères accentués du français, par exemple. Ainsi, on peut très bien mettre des accents dans les commentaires.
Oui, mais tu ne sais pas à l'avance ce qui sera accepté. Une implémentation peut très bien refuser tout caractère accentué.
Pas s'il est dans les commentaires.
-- Richard
Antoine Leca
Bonjour Emmanuel, joyeux Noël. On ne t'avais pas lu ces derniers jours, je croyais que tu étais au ski (veinard). Mais on dirait que non.
In news:43ad8cd6$0$25519$, Emmanuel Delahaye va escriure:
/* Happy XMas in C, Ansi-style */ /* * Send XMas wishes to every body * Adresse des voeux de Noël à la cité d'Évry * */
Des caractères non standards dans un code source C réputé 'ANSI'?
Où est le problème ?
C'est une provocation ?
Tu parles de ton message à toi ? ;-)
Antoine
Bonjour Emmanuel, joyeux Noël.
On ne t'avais pas lu ces derniers jours, je croyais que tu étais au ski
(veinard). Mais on dirait que non.
In news:43ad8cd6$0$25519$79c14f64@nan-newsreader-07.noos.net,
Emmanuel Delahaye va escriure:
/* Happy XMas in C, Ansi-style */
/*
* Send XMas wishes to every body
* Adresse des voeux de Noël à la cité d'Évry
*
*/
Des caractères non standards dans un code source C réputé 'ANSI'?
Bonjour Emmanuel, joyeux Noël. On ne t'avais pas lu ces derniers jours, je croyais que tu étais au ski (veinard). Mais on dirait que non.
In news:43ad8cd6$0$25519$, Emmanuel Delahaye va escriure:
/* Happy XMas in C, Ansi-style */ /* * Send XMas wishes to every body * Adresse des voeux de Noël à la cité d'Évry * */
Des caractères non standards dans un code source C réputé 'ANSI'?
Où est le problème ?
C'est une provocation ?
Tu parles de ton message à toi ? ;-)
Antoine
Antoine Leca
In news:43adec8b$0$6477$, loufoque va escriure:
Le C ANSI n'impose qu'une seule chose par rapport au charset utilisé : que les chiffres se trouvent à la suite.
Euh... non ; il y a beaucoup plus de conditions que cela, la plupart étant du genre évidentes en général, mais contraignent les environnements bizarres (qui sont le sujet sous-jacent ici).
C est conçu pour fonctionner avec n'importe quel charset.
Non. Par exemple, si tu travailles en environnement EBCDIC multinational, C possède des lacunes (impossible d'écrire ! et | sans ambiguïté). De même, difficile de programmer en C sans distinction minuscule-majuscule.
Il n'y donc pas de caractères standards et non standards...
Ouarf !
D'autant que notre cher ami a bien indiqué utiliser ISO-8859-15 et que cela tient sur 8 bits, la taille usuelle d'un byte et donc d'un char.
Ooooooouuuuuuuuuuuuuuaaaaaaaaaaaaaaaaaaaaaaarf !
On pourrait même utiliser UCS-32 sur une plateforme ou un byte c'est 32 bits.
UCS-32, un jeu de caractère bien connu... Des nombreuses « plateformes » utilisant 32 bits pour un "byte", je pense que seule le DS9k possède un compilateur capable d'accepter cela.
Antoine
In news:43adec8b$0$6477$626a54ce@news.free.fr,
loufoque va escriure:
Le C ANSI n'impose qu'une seule chose par rapport au charset utilisé :
que les chiffres se trouvent à la suite.
Euh... non ; il y a beaucoup plus de conditions que cela, la plupart étant
du genre évidentes en général, mais contraignent les environnements bizarres
(qui sont le sujet sous-jacent ici).
C est conçu pour fonctionner avec n'importe quel charset.
Non. Par exemple, si tu travailles en environnement EBCDIC multinational, C
possède des lacunes (impossible d'écrire ! et | sans ambiguïté). De même,
difficile de programmer en C sans distinction minuscule-majuscule.
Il n'y donc pas de caractères standards et non standards...
Ouarf !
D'autant que notre cher ami a bien indiqué utiliser ISO-8859-15 et que
cela tient sur 8 bits, la taille usuelle d'un byte et donc d'un char.
Ooooooouuuuuuuuuuuuuuaaaaaaaaaaaaaaaaaaaaaaarf !
On pourrait même utiliser UCS-32 sur une plateforme ou un byte c'est
32 bits.
UCS-32, un jeu de caractère bien connu...
Des nombreuses « plateformes » utilisant 32 bits pour un "byte", je pense
que seule le DS9k possède un compilateur capable d'accepter cela.
Le C ANSI n'impose qu'une seule chose par rapport au charset utilisé : que les chiffres se trouvent à la suite.
Euh... non ; il y a beaucoup plus de conditions que cela, la plupart étant du genre évidentes en général, mais contraignent les environnements bizarres (qui sont le sujet sous-jacent ici).
C est conçu pour fonctionner avec n'importe quel charset.
Non. Par exemple, si tu travailles en environnement EBCDIC multinational, C possède des lacunes (impossible d'écrire ! et | sans ambiguïté). De même, difficile de programmer en C sans distinction minuscule-majuscule.
Il n'y donc pas de caractères standards et non standards...
Ouarf !
D'autant que notre cher ami a bien indiqué utiliser ISO-8859-15 et que cela tient sur 8 bits, la taille usuelle d'un byte et donc d'un char.
Ooooooouuuuuuuuuuuuuuaaaaaaaaaaaaaaaaaaaaaaarf !
On pourrait même utiliser UCS-32 sur une plateforme ou un byte c'est 32 bits.
UCS-32, un jeu de caractère bien connu... Des nombreuses « plateformes » utilisant 32 bits pour un "byte", je pense que seule le DS9k possède un compilateur capable d'accepter cela.