donc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
donc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
donc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
Sauf qu'en général, la taille d'un fichier ne tient pas sur un int.
Si le fseek est assez sûr, le ftell pourrait renvoyer n'importe
quoi. Pour déterminer la position dans un fichier, la fonction
Sauf qu'en général, la taille d'un fichier ne tient pas sur un int.
Si le fseek est assez sûr, le ftell pourrait renvoyer n'importe
quoi. Pour déterminer la position dans un fichier, la fonction
Sauf qu'en général, la taille d'un fichier ne tient pas sur un int.
Si le fseek est assez sûr, le ftell pourrait renvoyer n'importe
quoi. Pour déterminer la position dans un fichier, la fonction
"Laurent" a écrit dans le message de news:
btk39j$l34$c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
#include <stdio.h> => bon pour les E/S C, pas ici
void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
char Carac[1] pas très élégant => char Carac; // voir plus loin
ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
=> test dans boucle peu élégant
Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
input.get( Carac ); // lit 1 caractere
Taille++; // incr
}
}
else {
cout << "blabla..." << endl;
}cout << "Taille : " << Taille << " octets.";
}
Et voilà.
"Laurent" <lthermy@wanadoo.fr> a écrit dans le message de news:
btk39j$l34$1@news-reader4.wanadoo.fr...
c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
#include <stdio.h> => bon pour les E/S C, pas ici
void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
char Carac[1] pas très élégant => char Carac; // voir plus loin
ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
=> test dans boucle peu élégant
Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
input.get( Carac ); // lit 1 caractere
Taille++; // incr
}
}
else {
cout << "blabla..." << endl;
}
cout << "Taille : " << Taille << " octets.";
}
Et voilà.
"Laurent" a écrit dans le message de news:
btk39j$l34$c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
#include <stdio.h> => bon pour les E/S C, pas ici
void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
char Carac[1] pas très élégant => char Carac; // voir plus loin
ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
=> test dans boucle peu élégant
Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
input.get( Carac ); // lit 1 caractere
Taille++; // incr
}
}
else {
cout << "blabla..." << endl;
}cout << "Taille : " << Taille << " octets.";
}
Et voilà.
"Régis Troadec" wrote in message
news:<btkri2$3g5$..."Laurent" a écrit dans le message de news:
btk39j$l34$c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Qu'il trouve un eof() dès le premier input.read(), j'imagine. C'est ce
qu'il a dit, de toute façon.Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
Je suppose qu'il a assez de bon sens pour d'abord vérifier qu'il a
lancé les deux versions depuis le même répertoire, et que le fichier à
ouvrir était bien présent.#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
Peut-être. En fait, je vois mal comment on pourrait implémenter
fstream.h sans inclure iostream.h, mais formellement, il n'y a aucune
garantie. En tout cas, c'est en général considéré une bonne pratique
d'include tout ce dont on a besoin, même quand on le sait inclu
indirectement.#include <stdio.h> => bon pour les E/S C, pas ici
En général (et ici), oui, mais il ne faut pas oublier que c'est toujours
dans <stdio.h> (ou <cstdio>) que sont définis remove et rename.void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
Pas du tout. Taille non initialisée implique Taille non initialisée. La
première lecture en donne un comportement indéfini. Typiquement, tu as
simplement une valeur au hazard. En mode debug, un bon compilateur
pourrait l'initialiser avec quelque chose de marquant (0xdeadbeef a une
certaine popularité). Voire même y associer un flag caché qu'il teste
avant la lecture, pour générer une erreur (échec d'assertion) dans le
cas d'un accès sans écriture préalable.
Dans un cas aussi simple que ceci, j'imagine que la plupart des
compilateur donnerait un avertissement, au moins si on a activé
l'optimisation (pour qu'ils fassent l'analyse de flux nécessaire).char Carac[1] pas très élégant => char Carac; // voir plus loin
Tout à fait d'accord. J'ai supposé (peut-être à tort, mais je donne
toujours la bénéfice de la doute) qu'il avait commencé avec quelque
chose de plus compliqué, avec peut-être un buffer plus grand, et que le
[1] était le résultat d'avoir simplifier.ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
En somme, tu sais qu'il y a des choses qui se passe derrier ton dos,
mais tu ne veux surtout pas que le lecteur le sache. Dans ce cas-ci, on
peut supposer évidemment que le lecteur sache aussi ce que fait
ifstream, et donc, qu'il n'y a pas vraiment dissimilation. Bien que, vue
la question, et ta réponse...input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
Il n'y a pas de sinon. Le traitement d'un fichier qu'on ne peut pas
ouvrir n'est pas le même que le traitement d'un fichier vide.=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
Moi, aussi, si on lit caractère par caractère, j'utiliserais get.
Quant à binary, il faudrait d'abord savoir ce qu'il veut faire.=> test dans boucle peu élégant
Mais fréquent. Il n'y a pas de solution élégante, en fait. C'est
pourquoi la question se trouve discutée si souvent.Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
Comme j'ai indiqué par ailleurs, ios::good() est une fonction sans la
moindre utilité.input.get( Carac ); // lit 1 caractere
Taille++; // incr
Et si la lecture échoue ? Ce qui va arriver forcement à la fin. Tu
compte un de trop.}
}
else {
cout << "blabla..." << endl;
}cout << "Taille : " << Taille << " octets.";
}
Et voilà.
Tu l'as testé ? Y compris vérifié que le résultat était juste ?
--
James Kanze GABI Software mailto:
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
"Régis Troadec" <regt@wanadoo.fr> wrote in message
news:<btkri2$3g5$1@news-reader3.wanadoo.fr>...
"Laurent" <lthermy@wanadoo.fr> a écrit dans le message de news:
btk39j$l34$1@news-reader4.wanadoo.fr...
c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Qu'il trouve un eof() dès le premier input.read(), j'imagine. C'est ce
qu'il a dit, de toute façon.
Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
Je suppose qu'il a assez de bon sens pour d'abord vérifier qu'il a
lancé les deux versions depuis le même répertoire, et que le fichier à
ouvrir était bien présent.
#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
Peut-être. En fait, je vois mal comment on pourrait implémenter
fstream.h sans inclure iostream.h, mais formellement, il n'y a aucune
garantie. En tout cas, c'est en général considéré une bonne pratique
d'include tout ce dont on a besoin, même quand on le sait inclu
indirectement.
#include <stdio.h> => bon pour les E/S C, pas ici
En général (et ici), oui, mais il ne faut pas oublier que c'est toujours
dans <stdio.h> (ou <cstdio>) que sont définis remove et rename.
void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
Pas du tout. Taille non initialisée implique Taille non initialisée. La
première lecture en donne un comportement indéfini. Typiquement, tu as
simplement une valeur au hazard. En mode debug, un bon compilateur
pourrait l'initialiser avec quelque chose de marquant (0xdeadbeef a une
certaine popularité). Voire même y associer un flag caché qu'il teste
avant la lecture, pour générer une erreur (échec d'assertion) dans le
cas d'un accès sans écriture préalable.
Dans un cas aussi simple que ceci, j'imagine que la plupart des
compilateur donnerait un avertissement, au moins si on a activé
l'optimisation (pour qu'ils fassent l'analyse de flux nécessaire).
char Carac[1] pas très élégant => char Carac; // voir plus loin
Tout à fait d'accord. J'ai supposé (peut-être à tort, mais je donne
toujours la bénéfice de la doute) qu'il avait commencé avec quelque
chose de plus compliqué, avec peut-être un buffer plus grand, et que le
[1] était le résultat d'avoir simplifier.
ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
En somme, tu sais qu'il y a des choses qui se passe derrier ton dos,
mais tu ne veux surtout pas que le lecteur le sache. Dans ce cas-ci, on
peut supposer évidemment que le lecteur sache aussi ce que fait
ifstream, et donc, qu'il n'y a pas vraiment dissimilation. Bien que, vue
la question, et ta réponse...
input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
Il n'y a pas de sinon. Le traitement d'un fichier qu'on ne peut pas
ouvrir n'est pas le même que le traitement d'un fichier vide.
=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
Moi, aussi, si on lit caractère par caractère, j'utiliserais get.
Quant à binary, il faudrait d'abord savoir ce qu'il veut faire.
=> test dans boucle peu élégant
Mais fréquent. Il n'y a pas de solution élégante, en fait. C'est
pourquoi la question se trouve discutée si souvent.
Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
Comme j'ai indiqué par ailleurs, ios::good() est une fonction sans la
moindre utilité.
input.get( Carac ); // lit 1 caractere
Taille++; // incr
Et si la lecture échoue ? Ce qui va arriver forcement à la fin. Tu
compte un de trop.
}
}
else {
cout << "blabla..." << endl;
}
cout << "Taille : " << Taille << " octets.";
}
Et voilà.
Tu l'as testé ? Y compris vérifié que le résultat était juste ?
--
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
"Régis Troadec" wrote in message
news:<btkri2$3g5$..."Laurent" a écrit dans le message de news:
btk39j$l34$c'est simple, ce programme fonctionne normallement sans debug, et en
debug, il me trouve un eof() des le premier input.read()
JE NE COMPRENDS PAS !!!!!!!!!!!
le "ça marche pas en debug mais autrement oui" sous Visual reste vague
dans ton post : qu'entends-tu par là ?
Qu'il trouve un eof() dès le premier input.read(), j'imagine. C'est ce
qu'il a dit, de toute façon.Lances-tu l'exécutable du dossier de la version debug (par rapport à
celui de la release), auquel cas "fichier.txt" n'y est peut-être pas
présent ?
Je suppose qu'il a assez de bon sens pour d'abord vérifier qu'il a
lancé les deux versions depuis le même répertoire, et que le fichier à
ouvrir était bien présent.#include <iostream.h>
#include <fstream.h>
#include <stdio.h>
headers superflus :
#include <iostream.h> => inclus avec fstream
Peut-être. En fait, je vois mal comment on pourrait implémenter
fstream.h sans inclure iostream.h, mais formellement, il n'y a aucune
garantie. En tout cas, c'est en général considéré une bonne pratique
d'include tout ce dont on a besoin, même quand on le sait inclu
indirectement.#include <stdio.h> => bon pour les E/S C, pas ici
En général (et ici), oui, mais il ne faut pas oublier que c'est toujours
dans <stdio.h> (ou <cstdio>) que sont définis remove et rename.void main(void)
{
ifstream input;
char Carac[1];
int Taille;
Taille non initialisée => int Taille = 0;
Pas du tout. Taille non initialisée implique Taille non initialisée. La
première lecture en donne un comportement indéfini. Typiquement, tu as
simplement une valeur au hazard. En mode debug, un bon compilateur
pourrait l'initialiser avec quelque chose de marquant (0xdeadbeef a une
certaine popularité). Voire même y associer un flag caché qu'il teste
avant la lecture, pour générer une erreur (échec d'assertion) dans le
cas d'un accès sans écriture préalable.
Dans un cas aussi simple que ceci, j'imagine que la plupart des
compilateur donnerait un avertissement, au moins si on a activé
l'optimisation (pour qu'ils fassent l'analyse de flux nécessaire).char Carac[1] pas très élégant => char Carac; // voir plus loin
Tout à fait d'accord. J'ai supposé (peut-être à tort, mais je donne
toujours la bénéfice de la doute) qu'il avait commencé avec quelque
chose de plus compliqué, avec peut-être un buffer plus grand, et que le
[1] était le résultat d'avoir simplifier.ouverture de flux plus simple (ios::in est par defaut) => ifstream
input("fichier.txt"); // open à virer en dessous
En somme, tu sais qu'il y a des choses qui se passe derrier ton dos,
mais tu ne veux surtout pas que le lecteur le sache. Dans ce cas-ci, on
peut supposer évidemment que le lecteur sache aussi ce que fait
ifstream, et donc, qu'il n'y a pas vraiment dissimilation. Bien que, vue
la question, et ta réponse...input.open("fichier.txt",ios::in);
do
{
input.read(Carac, sizeof(Carac));
if(input.good())
{
Taille++;
}
}
while(!input.eof());
=> Tester si flux bien ouvert avant et prevoir une gestion sinon:
Il n'y a pas de sinon. Le traitement d'un fichier qu'on ne peut pas
ouvrir n'est pas le même que le traitement d'un fichier vide.=> get (lit 1 caractère) plus facile que read (utilisé plutôt pour flux
binaire), sinon => input.read(&Carac, sizeof(Carac));
Moi, aussi, si on lit caractère par caractère, j'utiliserais get.
Quant à binary, il faudrait d'abord savoir ce qu'il veut faire.=> test dans boucle peu élégant
Mais fréquent. Il n'y a pas de solution élégante, en fait. C'est
pourquoi la question se trouve discutée si souvent.Je te propose :
if( input ) {
while ( input.good() ) { // tt que eof non atteinte ou pas
d'erreur
Comme j'ai indiqué par ailleurs, ios::good() est une fonction sans la
moindre utilité.input.get( Carac ); // lit 1 caractere
Taille++; // incr
Et si la lecture échoue ? Ce qui va arriver forcement à la fin. Tu
compte un de trop.}
}
else {
cout << "blabla..." << endl;
}cout << "Taille : " << Taille << " octets.";
}
Et voilà.
Tu l'as testé ? Y compris vérifié que le résultat était juste ?
--
James Kanze GABI Software mailto:
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
"Michel Michaud" writes:Je lis ceci dans la norme C89 (la seule norme C que j'ai et il me
semble celle sur laquelle est basé C++) :
The ftell function obtains the current value of the file
position indicator [...]. For a binary stream, the value is
the number of characters from the beginning of the file. [...]
Il me semble donc qu'avec un stream en mode binaire, ça
fonctionne pas si mal. Et ftell renvoie un long par ailleur...
Et voilà le problème. Sur pas mal de systèmes, encore
aujourd'hui, un long, ça n'a que 32 bits. Or qu'un système
aujourd'hui qui limite la taille d'un fichier à 2^32, c'est vraiment
taré (et je n'en connais pas). Alors, quoiqu'en dit la norme...
En fait, déjà avant la norme C90, le problème était connu.
C'est pour ça que C90 a introduit fpos_t et fgetpos/fsetpos. Les
veilles fonctions, fseek et ftell, continuent à fonctionner comme
avant dans les cas où elles peuvent marcher (ce qui devient assez
rare de nos jours), mais le code nouveau doit se servir des
nouvelles.
"Michel Michaud" <mm@gdzid.com> writes:
Je lis ceci dans la norme C89 (la seule norme C que j'ai et il me
semble celle sur laquelle est basé C++) :
The ftell function obtains the current value of the file
position indicator [...]. For a binary stream, the value is
the number of characters from the beginning of the file. [...]
Il me semble donc qu'avec un stream en mode binaire, ça
fonctionne pas si mal. Et ftell renvoie un long par ailleur...
Et voilà le problème. Sur pas mal de systèmes, encore
aujourd'hui, un long, ça n'a que 32 bits. Or qu'un système
aujourd'hui qui limite la taille d'un fichier à 2^32, c'est vraiment
taré (et je n'en connais pas). Alors, quoiqu'en dit la norme...
En fait, déjà avant la norme C90, le problème était connu.
C'est pour ça que C90 a introduit fpos_t et fgetpos/fsetpos. Les
veilles fonctions, fseek et ftell, continuent à fonctionner comme
avant dans les cas où elles peuvent marcher (ce qui devient assez
rare de nos jours), mais le code nouveau doit se servir des
nouvelles.
"Michel Michaud" writes:Je lis ceci dans la norme C89 (la seule norme C que j'ai et il me
semble celle sur laquelle est basé C++) :
The ftell function obtains the current value of the file
position indicator [...]. For a binary stream, the value is
the number of characters from the beginning of the file. [...]
Il me semble donc qu'avec un stream en mode binaire, ça
fonctionne pas si mal. Et ftell renvoie un long par ailleur...
Et voilà le problème. Sur pas mal de systèmes, encore
aujourd'hui, un long, ça n'a que 32 bits. Or qu'un système
aujourd'hui qui limite la taille d'un fichier à 2^32, c'est vraiment
taré (et je n'en connais pas). Alors, quoiqu'en dit la norme...
En fait, déjà avant la norme C90, le problème était connu.
C'est pour ça que C90 a introduit fpos_t et fgetpos/fsetpos. Les
veilles fonctions, fseek et ftell, continuent à fonctionner comme
avant dans les cas où elles peuvent marcher (ce qui devient assez
rare de nos jours), mais le code nouveau doit se servir des
nouvelles.
"Michel Michaud" writes:Dans news:btm5nt$if1$, Thomasdonc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
Moi, je réagis fortement (et négativement) quand mes
élèves prennent la peine d'écrire un commentaire et qu'il
ne correspond pas à ce qu'il commente !!!
En général, les commentaires qui expliquent ce qui est évident
sont à éviter, même s'ils sont vrais. :-)
"Michel Michaud" <mm@gdzid.com> writes:
Dans news:btm5nt$if1$1@news.tu-darmstadt.de, Thomas
donc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
Moi, je réagis fortement (et négativement) quand mes
élèves prennent la peine d'écrire un commentaire et qu'il
ne correspond pas à ce qu'il commente !!!
En général, les commentaires qui expliquent ce qui est évident
sont à éviter, même s'ils sont vrais. :-)
"Michel Michaud" writes:Dans news:btm5nt$if1$, Thomasdonc
if( input ) {
while ( input.good() ) { // tt que eof non atteinte
Moi, je réagis fortement (et négativement) quand mes
élèves prennent la peine d'écrire un commentaire et qu'il
ne correspond pas à ce qu'il commente !!!
En général, les commentaires qui expliquent ce qui est évident
sont à éviter, même s'ils sont vrais. :-)
