Discussion :

[stephl]

J'utilise GCC sous Windows par l'intermédiaire de Cygwin

Si j'ai bonne mémoire, cygwin émule (ou quelque chose dans le genre) Linux. Je pense que les librairies fournies utilisent donc le format UNIX pour les fins de ligne. D'où le problème. Peut-être vaut-il mieux utiliser gcc mingw?

[koktel_dfr]

Si j'ai bonne mémoire, cygwin émule (ou quelque chose dans le genre) Linux. Je pense que les librairies fournies utilisent donc le format UNIX pour les fins de ligne. D'où le problème. Peut-être vaut-il mieux utiliser gcc mingw?

Le truc c'est que je voudrais que mon code sois portable sous UNIX, c'est justement pour ca que j'utilise GCC sous windows. Enfin, au pire si il n'y a qu'un caractere de fin de ligne a changer ce n'est pas bien grave.

[souviron34]

Le truc c'est que je voudrais que mon code sois portable sous UNIX, c'est justement pour ca que j'utilise GCC sous windows. Enfin, au pire si il n'y a qu'un caractere de fin de ligne a changer ce n'est pas bien grave.

ben si tu laisses le \r ça sera portable....

Pour mémoire, le \r ramène le curseur en début de ligne. Vu que le \n fait normalement CR et LF, ça ne changera rien..

[stephl]

Sur les implémentations Windows des bibliothèques, "\n" est traduit en CR+LF lors d'une écriture de fichier, et réciproquement en lecture CR+LF est traduit en "\n".
Il n'y a pas à proprement parler de problème de portabilité là. De toute façon, seul le source sera portable. Il faudra le compiler une fois sous UNIX et une fois sous Windows. Dans le source doit figurer "\n" pour effectuer un passage à la ligne suivante. C'est au rôle de la bibliothèque d'effectuer les traductions éventuelles.

[souviron34]

Sur les implémentations Windows des bibliothèques, "\n" est traduit en CR+LF lors d'une écriture de fichier, et réciproquement en lecture CR+LF est traduit en "\n".
Il n'y a pas à proprement parler de problème de portabilité là. De toute façon, seul le source sera portable. Il faudra le compiler une fois sous UNIX et une fois sous Windows. Dans le source doit figurer "\n" pour effectuer un passage à la ligne suivante. C'est au rôle de la bibliothèque d'effectuer les traductions éventuelles.

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

[stephl]

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

Le message disait:

je voudrais que mon code sois portable sous UNIX

Mais s'il s'agit de la portabilité du fichier résultant, je suis d'accord avec vous: le problème se posera et il faudra faire un choix.

[koktel_dfr]

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

Effectivement je souhaiterais que les deux soient portable, maitenant un fichier texte est un fichier texte, peut importe qu'il soit sous windows ou unix. Enfin, quoique c'est ce que je pensais...mais a mon avis c'est plus un problème de bloc notes car comme je l'ai dit plus haut mon fichier texte se lit sans problème sous context même sans le \r.

Je sais bien qu'il faudra le recompiler mais au moins je n'aurais pas à écrire deux fois le programme, une fois sous windows et une fois sous unix.

[Médinoc]

Portable ou non, il faudra recompiler de toute façon...

Et sous UNIX, écrire \r\n donnera des fichiers qui ne seront pas correctement affichés par les éditeurs de texte les plus basiques d'unix (vi affichera ^M à la fin de chaque ligne). Par contre, ils seront correctement affichés par le bloc-note.

Donc, le gcc à utiliser sous Windows n'est pas celui de Gygwin, mais MinGW.

[Thierry Chappuis]

non je suppose que ce qu'il voulait dire c'est pour que le fichier résultant soit portable (et éventiellement le prgramme, mais comme tu dis faudra le recompiler)

En ce qui concerne la portabilité du fichier, le mieux est à mon avis de passer par un utilitaire tel que dos2unix/unix2dos ou quelque chose du genre qui s'occupe de la convertion des fichiers. C'est ce que je fais, et je laisse ensuite le runtime du C gérer la lecture et l'écriture des caractères de fin de ligne de manière transparente.

Thierry

[gl]

Voici le code concernant l'écriture des lignes de mon log :

Code :

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

1
2
3
4
5
6
7
8
9
 
FILE *f_out;
char logLine[200];
 
sprintf(logLine,"[ERROR] %s ---> %s - %s\n",functionName, errorDescription,error);
 
f_out = fopen(logFile,"a");
fputs(logLine, f_out);
fclose(f_out);

Je trouve plutot dommage de devoir déclarer un buffer de taille 200 sachant que ma ligne de log peut ne pas dépasser les 50... aurait-il un moyen de gérer ca dynamiquement. Déterminer la taille de la ligne est facile avec strlen(), mais que mettre au niveau de la déclaration de logLine ?

Merci.

Sans revenir sur les remarques pertinentes et les corrections qu'ont deja fournit d'autre posteurs, quel est l'interet de la chaine temporaire ? Si tu ne l'utilises pas en dehors de cet extrait, le code suivant

Code :

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

1
2
3
4
5
6
7
8
 
FILE *f_out;
f_out = fopen(logFile,"a");
if(f_out != NULL)
{
   fprintf(f_out, "[ERROR] %s ---> %s - %s\n", functionName, errorDescription,error);
   fclose(f_out);
}

est bien plus simple.

[souviron34]

+10

On est vraiment c.ns de pas y avoir pensé plus tôt

MAis bon, on regardait pas ça.. Mais quand même..

Bravo