message : "lines ending with only a carriage..."

Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> wrote in message
news:<401ee327$0$2965$626a54ce@news.free.fr>...

le Sunday 01 February 2004 15:49, kanze@gabi-soft.fr écrivit :

Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
|> le Sunday 01 February 2004 13:14, kanze@gabi-soft.fr écrivit :
|> > probablement de maintenir les fichiers dans le format
|> > normalisé (qui est pour une fois celui qu'utilise Microsoft),
|> > et d'utiliser un

|> ah bon ? c'est la norme C++ qui précise ça ?

C'est la norme ASCII. Celle qui définit le jeu de caractères dont tu
te sers.

ah d'accord, je viens de voir la liste des codes Ascii 0-31
(non-printable), qui inclue CR et LF. Effectivement si on cherche à
donner un sens à un maximum de ces symboles du point de vue plus
abstrait du codage de texte, une ligne pourrait se terminer en CR/LF
par analogie aux machines à écrire (et terminaux antiques).

La signification de LF, c'est bien « line feed », c'est à dire saut de
ligne. Mais pour être honnête, la norme ASCII dit clairement que c'est
« implementation defined » si un saut de ligne provoque un retour
chariot implicit ou non. Ça dépend du hardware.

Je trouve que le choix de CR/LF ou LF seul pour signifier la fin de
ligne dépasse de tte façon le cadre su standard ascii, unix a choisi
un standard, windows un autre (plus proche des significations
originales de CR/LF).

Oui et non. Tout dépend de ce que tu entends par ligne. Sous Unix, en
fait, on considère la plupart du temps les lignes comme des
enregistrements, et la norme C a consacré cette idée avec sa définition
de mode texte des entrées/sorties. Mais en ASCII, le caractère pour
séparer les enregistrements, c'est RS (0x1E).

Mais finalement toute la partie ASCII qui sort des caractères lisibles
est en fait un standard de terminal, pas de codage du texte.

C'est plus que ça ; ASCII donne une sémantique plus ou moins précise à
ces caractères. Mais c'est largement une sémantique d'attente, comme la
sémantique d'un reinterpret_cast entre un pointeur et un entier en C++
(qui doit être sans surprises pour celui qui connaît l'architecture de
la machine). Aussi, certains caractères spécifient un comportement du
terminal (typiquement imprimante, à l'époque), par exemple BEL, TAB ou
CR, LF, tandis que d'autres n'ont une signification que dans le
contexte de la transmission de données, comme STX, ETX, ou NAK. Et il y
en a d'autres.

En attendant, les normes de l'Internet précise aussi CRLF:-), par
exemple dans les en-têtes de SMTP, NNTP ou HTTP.

D'une côté, je suis d'accord avec toi, et il n'y a aucune raison pour
qu'un système ne choisit pas la convention qui lui convient, interne. Le
problème, c'est qu'avec NFS, il n'y a plus d'interne -- idéalement, NFS
aurait aussi la notion de fichier texte et de fichier binaire, comme
C/C++ et FTP, mais je ne crois pas que ça risque de changer maintenant.

ça rime pas à grand chose d'essayer de reprendre le plus possible de
ces choses terminalesques dans un standard de codage de texte.

Dans les codages de texte plus récents et plus complets (iso*,
unicode), il y a un symbole 'fin de ligne', ou bien c'est encore
remplacé par emprunt de CR/et/ou/LF au domaine des terminaux ?

Tu veux dire comme u0085, Unicode NEXT LINE ? D'après le code,
j'imagine qu'il fait partie des ISO 8859-n aussi.

M'enfin
ensuite c'est la porte ouverte à des symboles pour fin de paragraphe,
fin de chapitre.. finalement la vraie place de la 'fin de ligne' n'est
peut être pas dans le jeu de caractères mais dans l'interpretation du
flux de caractères, qui ne devrait pas inclure de fin de ligne du tout
mais seulement l'indication de sa structure, comme ça se passe en
html..

C'est sans doute la vraie solution quand il s'agit de texte. Les fins de
lignes (CRLF, etc.) dans la texte ne servent que pour faciliter
l'affichage du texte source, dans l'éditeur, etc. Mais on n'en est pas
là, et si une ligne dans ton programme C++ commence #define, la fin de
la ligne a une signification sémantique plus que de simples éspaces.

enfin bon, en attendant on tape Entrée un peu partout pour donner un
minimu de structure aux codes sources et messages texte, et c'est pas
idéal mais c'est pas si mal..
enfin, pour les codes sources ce serait tout de meme mieux que tout le
formattage soit fait par l'éditeur/visualiseur, et que le source en
soit indépendant.

Ce qui m'amnèe à une question finalement en thème : y a des outils
pour réindenter complètement (y compris ajouter/supprimer des fins de
ligne) des sources C++ ?

Il y a « indent-region » en Emacs (que j'ai lié à la touche ^C-N chez
moi), mais il ne changerait que l'indentation -- il ne change rien au
delà du premier non-blanc dans la ligne, et il ne supprime ni inserte
jamais de 'n'.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze@gabi-soft.fr wrote:

Oui et non. Tout dépend de ce que tu entends par ligne. Sous Unix, en
fait, on considère la plupart du temps les lignes comme des
enregistrements, et la norme C a consacré cette idée avec sa définition
de mode texte des entrées/sorties. Mais en ASCII, le caractère pour
séparer les enregistrements, c'est RS (0x1E).

effectivement, c'est bien le rôle que joue n en pratique.
mais bon, si j'ai bien compris la norme C définit LF pour ça, ça en fait une
norme au moins aussi fondamentale que les normes du net que tu cites.
(d'ailleurs qui ne s'applique qu'aux headers des messages transmis, pas au
texte lui même)

terminal (typiquement imprimante, à l'époque), par exemple BEL, TAB ou
CR, LF, tandis que d'autres n'ont une signification que dans le
contexte de la transmission de données, comme STX, ETX, ou NAK. Et il y
en a d'autres.

c'est un peu batârd de mélanger les 2 dans un seul standard, de nos jours on
ferait pas comme ça :)

D'une côté, je suis d'accord avec toi, et il n'y a aucune raison pour
qu'un système ne choisit pas la convention qui lui convient, interne. Le
problème, c'est qu'avec NFS, il n'y a plus d'interne -- idéalement, NFS
aurait aussi la notion de fichier texte et de fichier binaire, comme
C/C++ et FTP, mais je ne crois pas que ça risque de changer maintenant.

hof, finalement ça pose pas tant de problèmes que ça si ? vu que de toute
façon toutes les applications se doutent bien que LF signifie fin de ligne,
et que CR/LF aussi, ya pas de méprise possible.
Bien qu'en fait, avec des echanges par cvs et tout plein d'interaction
unix/windows il peut finir par arriver des choses étranges (des centaines
d'occurences de 'CR CR LF' d'origine incertaine dans le repository cvs de
boost par exemple)
Autant que les couches de transport ne se mêlent pas de ça, ça a plutot
tendance à compliquer les choses je trouve.

Tu veux dire comme u0085, Unicode NEXT LINE ? D'après le code,
j'imagine qu'il fait partie des ISO 8859-n aussi.

ah voilà, je me doutais que ça devait exister.

C'est sans doute la vraie solution quand il s'agit de texte. Les fins de
lignes (CRLF, etc.) dans la texte ne servent que pour faciliter
l'affichage du texte source, dans l'éditeur, etc. Mais on n'en est pas
là, et si une ligne dans ton programme C++ commence #define, la fin de
la ligne a une signification sémantique plus que de simples éspaces.

oui et pour les commentaire // aussi, c'est le seul vrai rôle des fins de
lignes dans du code source. (outre le fait qu'en pratique le compilateur
donne le num de ligne à laquelle il a diagnostiqué l'erreur, et que __LINE
est une macro bien pratique)
ça n'empecherait pas de laisser l'editeur gerer les fins de ligne..

Il y a « indent-region » en Emacs (que j'ai lié à la touche ^C-N chez
moi), mais il ne changerait que l'indentation -- il ne change rien au
delà du premier non-blanc dans la ligne, et il ne supprime ni inserte
jamais de 'n'.

oui j'utilise aussi, mais ça ne fait que regler l'indentation, pas le
formattage complet d'un fichier source.
Pour ça il faudrait avoir des algos qui pesent le pour et le contre
d'ajouter une nouvelle ligne au milieu d'un appel de fction à plusieurs
arguments selon la longueur de ligne résultante, le contexte, etc..

--
Sam

Samuel Krempp wrote:

oui et pour les commentaire // aussi, c'est le seul vrai rôle des fins de
lignes dans du code source. (outre le fait qu'en pratique le compilateur
donne le num de ligne à laquelle il a diagnostiqué l'erreur, et que __LINE
est une macro bien pratique)

Et grace à cette macro __LINE__, il y a même des programmes qui
deviennent incorrects si on ajoute une ligne blanche n'importe où, même
en dehors des endroits précités. En général, on les repère vite, ils
sont sur l'IOCCC...

--
Loïc

kanze@gabi-soft.fr wrote:

[Gros, long, énorme couic]

Enfin la situation n'est pas tout à fait désespérée,
je crois qu'il y a un portage de linux pour ibm390 :)

Tu n'as pas l'air de te rendre compte. S'il y a encore des utilisateurs
des IBM 390, c'est qu'ils ont besoin d'un système ultra stable, qui
marche.

Toi tu n'as pas l'air de te rendre compte que les lignes de mon messages
se terminent souvent par :) Elles ne sont donc pas nécessairement à
prendre au premier degré (les autres non plus, d'ailleurs, je n'aurais
pas cette prétention). Que tu le veuilles ou non, c'est ainsi, la vie
n'est pas uniquement faite de 0 et de 1, il y a plein de trucs entre les
deux :)

Je ne dispose pas de beaucoup de temps pour poursuivre ce débat,
d'autant plus passionnant que nous disons à peu près la même chose, ce
qui offre encore plus de possibilités d'ergoter sur tous les mots
pendant des pages. Donc je te laisse avec plaisir le dernier mot que
j'espère bien te voir relever avec brio.
Tiens, au fait, il me vient une question : c'est codé comment une fin de
page ?

Cordialement,
Jacques

PS. j'aime bien tes envolées d'autant plus lyriques que les sujets sont
sans intérêt. Ca me fait de la lecture bien amusante pendant mes pauses,
mais je n'ai hélas pas le temps de m'investir autant que toi dans tous
ces combats quotidiens que tu mènes contre la médiocrité.

On Tue, 03 Feb 2004 12:40:23 +0100, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr> wrote:

et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

ah bon ? ah oui, tout ce qui se base sur une ligne, c vrai..

Ce n'est pas le problème. Le problème que j'évoque, c'est que si
l'éditeur affiche le code d'une façon très différente du contenu du
fichier, on ne pourra pas ouvrir ledit fichier avec un autre éditeur
-- ou tout autre logiciel qui travaille sur du texte. C'est à peu près
ce qui se passe aujourd'hui avec les fichiers .doc de MS-Word.

--
;-)

On Tue, 03 Feb 2004 12:40:23 +0100, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr> wrote:

l'éditeur de code pourrait restreindre les libertés du codeur

Sans moi, merci. Je tiens à ma liberté.

le codeur taperait
seulement le code, au kilometre et l'éditeur l'afficherait comme il faut,
de manière adaptée à la structure du code.

Sauf qu'il faudrait un éditeur qui sache ce que le codeur a en tête
pour formater correctement le code...
Je suis presque sûr que je perdrais plus de temps à paramétrer un tel
système qu'à faire la mise en page moi-même.

Mon expérience de VB est assez éloignée, et je ne suis pas très chaud
pour revenir dessus, mais je crois me souvenir que l'éditeur se
permettait justement de mettre mon code en forme, et c'est assez
désagréable :-(

--
;-)

jz <jz@jz.jz> wrote in message
news:<40200b7b$0$18220$626a54ce@news.free.fr>...

kanze@gabi-soft.fr wrote:

Toi tu n'as pas l'air de te rendre compte que les lignes de mon
messages se terminent souvent par :) Elles ne sont donc pas
nécessairement à prendre au premier degré (les autres non plus,
d'ailleurs, je n'aurais pas cette prétention). Que tu le veuilles ou
non, c'est ainsi, la vie n'est pas uniquement faite de 0 et de 1, il y
a plein de trucs entre les deux :)

Ce n'est pas parce que je ne mets pas les :) qu'il faut prendre mes
contributions différemment. Comme tu dis, il y a beaucoup de nuances.
Mais je trouve parfois que ça vaut la peine de contradire ce qui a été
dit, soit justement pour montrer qu'il y a un autre côté, soit pour
profondir le raisonement, soit simplement pour m'amuser.

Je ne dispose pas de beaucoup de temps pour poursuivre ce débat,
d'autant plus passionnant que nous disons à peu près la même chose, ce
qui offre encore plus de possibilités d'ergoter sur tous les mots
pendant des pages. Donc je te laisse avec plaisir le dernier mot que
j'espère bien te voir relever avec brio.

Tiens, au fait, il me vient une question : c'est codé comment une fin
de page ?

Traditionnellement, FF (= Form Feed, 'f' en C/C++). Le nom, en tout
cas, renvoie au bon vieux temps du papier contenu et des imprimantes
lignes.

PS. j'aime bien tes envolées d'autant plus lyriques que les sujets sont
sans intérêt.

Merci. Je vois au moins que tu les comprends, et les prends dans le sens
que je les donne.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Samuel Krempp <krempp@crans.ens-cachan.fr> wrote in message
news:<bvockv$il6$1@discovery.ens-cachan.fr>...

kanze@gabi-soft.fr wrote:

Oui et non. Tout dépend de ce que tu entends par ligne. Sous Unix,
en fait, on considère la plupart du temps les lignes comme des
enregistrements, et la norme C a consacré cette idée avec sa
définition de mode texte des entrées/sorties. Mais en ASCII, le
caractère pour séparer les enregistrements, c'est RS (0x1E).

effectivement, c'est bien le rôle que joue n en pratique. mais bon,
si j'ai bien compris la norme C définit LF pour ça, ça en fait une
norme au moins aussi fondamentale que les normes du net que tu cites.
(d'ailleurs qui ne s'applique qu'aux headers des messages transmis,
pas au texte lui même)

La norme C est très claire qu'il s'agit d'une représentation interne, et
que la norme C ne cherche pas à influer sur les représentations
externes. Il faut dire que les représentations externes ont en général
précédées le langage C.

En fait, évidemment, à l'époque où C s'est développé, la « norme » pour
un système d'exploitation, c'était de gérer les fichiers disques avec
des enregistrements, qui était plus ou moins conçus comme des images de
cartes perforées. Les cartes perforées n'ayant pas de caractère de fin
de ligne ou de fin d'enregistrement, les fichiers ne l'avaient pas non
plus. La plupart des langages à l'époque reflétait ce fait, avec des
commandes comme WRITELN (en plus de WRITE) et une gestion de la fin de
ligne (ou d'enregistrement) à part. À l'époque, Unix était un peu à
part, à cet égard -- il n'était pas le seul système à considérer un
fichier comme un simple flux d'octets, mais ce n'était pas le cas des
systèmes réelement répandu : RSX-11, par exemple, ou les divers OS du
IBM 360.

Du coup, il y avait un problème dans la définition de C pour ces
machines. A priori, on voulait rester le plus près possible au C de Unix
(et de MS-DOS, qui a en fait copié pas mal de Unix en ce qui concerne la
gestion de fichiers), sans faire que les fichiers texte écrit en C ne
pouvait pas être lus par d'autres langages, et vice versa.

terminal (typiquement imprimante, à l'époque), par exemple BEL, TAB
ou CR, LF, tandis que d'autres n'ont une signification que dans le
contexte de la transmission de données, comme STX, ETX, ou NAK. Et
il y en a d'autres.

c'est un peu batârd de mélanger les 2 dans un seul standard, de nos
jours on ferait pas comme ça :)

De nos jours, il y a des protocols en couches, et il n'y a pas de
caractères de gestion de protocol, à proprement parlé.

Je ne sais pas quand le code ASCII a été normalisé. Il y était déjà
quand j'ai commencé l'informatique (début des années 70). Et je peux te
dire qu'à cette époque, les protocols aux couches c'étaient vraiment de
l'expérimental, chez IBM (OSI se base largement sur SNA) et quelques
universités. Pour la reste du monde, c'était LE protocol, qui
encompassait tout, depuis la gestion du modem jusqu'au formattage du
texte transmis.

C'est sûr que si on voulait définir un code complètement neuf, on s'y
prendrait différemment. (En fait, il me semble avoir lu quelque part que
soit Unicode, soit ISO 10646 ne normalise pas les codes de contrôle. Ils
en réserve le bloc, pour des raisons de compatibilité, mais c'est tout.)
Mais on ne va pas définir un code complètement neuf, parce que du coup,
on ne pourrait plus lire l'existant.

D'une côté, je suis d'accord avec toi, et il n'y a aucune raison
pour qu'un système ne choisit pas la convention qui lui convient,
interne. Le problème, c'est qu'avec NFS, il n'y a plus d'interne --
idéalement, NFS aurait aussi la notion de fichier texte et de
fichier binaire, comme C/C++ et FTP, mais je ne crois pas que ça
risque de changer maintenant.

hof, finalement ça pose pas tant de problèmes que ça si ? vu que de
toute façon toutes les applications se doutent bien que LF signifie
fin de ligne, et que CR/LF aussi, ya pas de méprise possible.

Et qu'est-ce qui se passe si je connecte un Apple au reseau ?
(Historiquement, la fin de ligne chez Apple était CR. Je ne sais pas ce
qu'il en est maintenant que l'OS Apple est un dialect d'Unix.) Mieux,
qu'est-ce qui se passe si je connecte un IBM 390 au reseau ? (La réponse
pratique : on ne partage pas les disques d'un IBM 390.)

En fait, il n'y a pas de problème parce qu'on évite les cas où ça ne
marche pas. Qu'on ne connecte pas les IBM 390 sur des reseaux locaux.

Bien qu'en fait, avec des echanges par cvs et tout plein d'interaction
unix/windows il peut finir par arriver des choses étranges (des
centaines d'occurences de 'CR CR LF' d'origine incertaine dans le
repository cvs de boost par exemple)

Autant que les couches de transport ne se mêlent pas de ça, ça a
plutot tendance à compliquer les choses je trouve.

FTP n'est pas une couche de transport. Ni NFS.

Le problème, c'est justement que ce n'est pas clair qui s'en occupe.
Logiquement : si je monte un répertoire NFS sur une machine Unix, je
vois un système de fichiers Unix, et si je le monte sous Windows, je
vois un système de fichiers Windows. Dans la pratique, c'est prèsque
vrai, mais seulement parce que Windows et Unix se ressemblent
énormement. En fait, si on s'acharne sur les histoires de CRLF/LF, c'est
parce que c'est à peu près la seule différence entre les deux (encore
que -- essaie de changer les droits groupe sous Unix, sur un fichier NFS
où le serveur tourne sous Windows.)

Logiquement, j'aimerais que tout soit transparent, et que ce soit
l'application qui me rend disponible les fichiers sur mon système (FTP
ou NFS) qui s'occupe de tout. Pratiquement, ce n'est pas le cas, ou ce
n'est le cas que partiellement. Du coup, on a des programmes qui ne
doivent pas avoir à s'en occuper qui s'en occupent aussi, et une
confusion complète.

Alternativement, on aurait pû dire dès le départ que la représentation
des fins de lignes dépend de l'implémentation, et qu'elle peut même
varier d'un fichier à un autre, voir d'une ligne à une autre, à
l'intérieur du même fichier, et qu'un programme correct sait s'en tirer.
Ou on aurait pu masquer le tout, et faire que les bibliothèques C/C++,
ainsi que NFS et FTP, connaissent la notion d'un enregistrement.

Tu veux dire comme u0085, Unicode NEXT LINE ? D'après le code,
j'imagine qu'il fait partie des ISO 8859-n aussi.

ah voilà, je me doutais que ça devait exister.

Entre exister et servir, il y a apparamment une différence :-).

C'est sans doute la vraie solution quand il s'agit de texte. Les
fins de lignes (CRLF, etc.) dans la texte ne servent que pour
faciliter l'affichage du texte source, dans l'éditeur, etc. Mais on
n'en est pas là, et si une ligne dans ton programme C++ commence
#define, la fin de la ligne a une signification sémantique plus que
de simples éspaces.

oui et pour les commentaire // aussi, c'est le seul vrai rôle des fins
de lignes dans du code source. (outre le fait qu'en pratique le
compilateur donne le num de ligne à laquelle il a diagnostiqué
l'erreur, et que __LINE est une macro bien pratique)
ça n'empecherait pas de laisser l'editeur gerer les fins de ligne..

Je ne sais pas. Comment est-ce que l'éditeur va déterminer la fin de mon
commentaire ?

En fait, c'est peut-être simplement le fait de l'habitude, mais j'aime
l'autre extrème -- que mon éditeur soit orienté ligne. Ce n'est pas pour
rien que j'utilise VIPER en Emacs, et que je me sers pas mal de vim.

Il y a « indent-region » en Emacs (que j'ai lié à la touche ^C-N
chez moi), mais il ne changerait que l'indentation -- il ne change
rien au delà du premier non-blanc dans la ligne, et il ne supprime
ni inserte jamais de 'n'.

oui j'utilise aussi, mais ça ne fait que regler l'indentation, pas le
formattage complet d'un fichier source.
Pour ça il faudrait avoir des algos qui pesent le pour et le contre
d'ajouter une nouvelle ligne au milieu d'un appel de fction à plusieurs
arguments selon la longueur de ligne résultante, le contexte, etc..

Pour ça, il faudrait en fait pouvoir parser le C++, je crois. Et pense
aux options qu'il faudra, pour supporter tous les styles existants (et à
venir).

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
r71120580nt8cqt343s52fqrc674j263ii@4ax.com...

On Tue, 03 Feb 2004 12:40:23 +0100, Samuel Krempp
<krempp@crans.truc.en.trop.ens-cachan.fr> wrote:

et les outils habituels de traitement de
texte (je pense à grep, par exemple) sont inutilisables.

ah bon ? ah oui, tout ce qui se base sur une ligne, c vrai..

Ce n'est pas le problème. Le problème que j'évoque, c'est que si
l'éditeur affiche le code d'une façon très différente du contenu du
fichier, on ne pourra pas ouvrir ledit fichier avec un autre éditeur
-- ou tout autre logiciel qui travaille sur du texte. C'est à peu près
ce qui se passe aujourd'hui avec les fichiers .doc de MS-Word.

Il me semble que pour aboutir à l'inconvénient que tu signales,
il faut que l'éditeur mette à jour le fichier sous un autre format
que l'originel. Je ne vois pas en quoi un affichage formaté qui
ne touche pas au fichier plomberait sa lecture ultérieure par
d'autres éditeurs - copie à revoir ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France

On Wed, 4 Feb 2004 22:49:00 +0100, "Alain Naigeon" <anaigeon@free.fr>
wrote:

Il me semble que pour aboutir à l'inconvénient que tu signales,
il faut que l'éditeur mette à jour le fichier sous un autre format
que l'originel.

Si tu crées un document sous Word, ce dernier enregistre le document
dans un format très différent de ce qui est affiché à l'écran (Il n'y
a pas de problème de conversion de fichier, puisque le document est
créé à partir de rien). Du coup, tu ne peux pas l'ouvrir avec un autre
logiciel (un éditeur de texte, grep, etc.) et obtenir quelque chose de
ressemblant à ce que tu vois affiché sous Word.

C'est déjà assez pénible avec Word, mais relativement justifié par la
richesse du formatage. Mais je n'aimerais vraiment pas que ce genre
d'inconvénients arrive avec le code C++.

--
;-)