wcout: comportement ~-~

Version imprimable

12/05/2012, 09h17
minnesota

wcout: comportement ~-~
Salut tout le monde,

J'ai un problème très spécial
Code:

1 2 3 4 5 6 7 std::wcout<< << L"A" // \u0041 << "\u000D\u000A\u000D\u000A" << L"B" // \u0042 << L"\r\n\r\n" << L"C" // \u0043 << std::endl;
La sortie devrait selon moi avoir cette allure

A....B....C..
410D0A0D0A420D0A0D0A430D0A

mais j'obtiens ça

A......B......C..
410D0D0A0D0D0A420D0D0A0D0D0A430D0A

Est ce qu'il y a quelque chose que j'ai fait mal, ou c'est parce que c'est moi :calim2:

EDIT:

la SL c'est libstdc++ (gnu/gcc)
12/05/2012, 12h48
screetch

sur quel OS?
le symbole de fin de ligne, c'est \n
ensuite la bibliothèque se charge, en mode texte (donc avec cout et wcout) de traduire ce \n dans la fin de ligne reglementaire sur la machine, soit \r sur les vieux mac, \n sous les bsd et unix recent et donc les nouveaux macs, et \r\n sous windows

si tu ecrits \r\n, la bibliothèque ecrira donc \r\r\n.
c'est en général invisible car \r est le retour au début de la ligne; quand on est au début de la ligne, c'est donc rien du tout.
12/05/2012, 14h42
minnesota

Oui, j'ai oublié, c'est sur windows.

En fait, ce bout de code c'est juste pour reproduire simplement le problème que je décris, mais la séquence \r\n\r\n a proprement dite provient d'une longue chaine elle-même issue d'un fichier Unicode. Lorsque je redirige la sortie de ma console vers un fichier, j'ai un éditeur texte qui me saute 3 lignes (soit 5 passages à la ligne) alors que 2 autres n'en sautent qu'une (soit 2 passages à la ligne, donc normale).

L'ennui c'est que ce premier éditeur supporte les trois types de fin de ligne (win, unix, mac), du coup avec ce genre de truc, il ne sait pas sur quel pied danser.

Y'a-t-il par hasard une option qui me permettrait de dire à wcout de ne pas faire de surenchère*quand il rencontre une séquence de ce genre ? (sans que j'ai moi même besoin de filtrer la chaine).

Merci.
12/05/2012, 23h26
screetch

si tu lis depuis un fichier texte, le même mécanisme devrait s'appliquer et tes \r\n seraient lus comme un simple \n. Je regarderais donc a ta place pourquoi ca n'est pas fait et si ca peut être corrigé plutot comme ca.
A mon avis tu utilises CreateFile pour ouvrir le fichier (qui ne fait pas cette conversion) et wcout pour afficher (qui effectue cette conversion) mais sans le code, c'est plutôt ma boule de cristal qui parle.
13/05/2012, 01h05
minnesota

Non, ma chaine je la reçois sous forme de paramètre, un pointeur sur un tableau de char et sa longueur, que je convertis en vue de son affichage. Je ne fais pas de manipulation directe sur le fichier source.

dans ce cas, je dirais

Code:

1
2
3
FILE*f=fdopen(0, "wb");
fwide(f, 1);
fwprintf(f, "\u000d\u000a");

13/05/2012, 12h03
screetch

je ne sais pas qui a mis un -1 sur mon post mais j'ai donc des questions:
- testé et ca ne marche pas?
- il y a une erreur?
- c'est du code C sur un forum C++?
quel était le problème?
13/05/2012, 13h47
minnesota

Non, c'est pas moi et je ne me le permettrais pas de la sorte. Je compense de suite.

En tout cas, je regarde ce que ça donne et je te tiens au courant. Merci.
13/05/2012, 13h49
screetch

non mais c'est peut être justifié, j'ai pit etre dit une connerie. mais ca a marché?
13/05/2012, 13h56
minnesota

J'ai édité entre temps :aie:
13/05/2012, 14h07
screetch
j'ai fait un peu de recherche et apparemment, si tu fais fclose après fdopen ca va fermer le fichier (stdout ici) ce qui n'est pas souhaitable.

pour corriger ca, plutot:
Code:

1 2 3 4 int newstdout = dup(0); FILE* f = fdopen(newstdout, "wb"); .... fclose(f);
13/05/2012, 14h56
JolyLoic

Plutôt que rediriger la console vers un fichier, ne pourrais-tu pas utiliser directement un fichier ? Comme ça, tu pourrais choisir de l'ouvrir en mode binaire ou texte.

D'abord merci à vous deux.

En effet JolyLoic mais rediriger la sortie vers un fichier c'est juste une option envisageable, comme on le ferait avec n'importe quel programme console. Quoique là, c'est en mode test, parce que c'est un essai, après il y aura une interface graphique, le problème ne se posera peut-être plus, mais ça me chiffonne quand même puisque j'utiliserais les flux.

Bon ben screetch, j'ai regardé ta proposition, rien à faire avec le fdopen(), à moins que je m'y prenne mal (ça fait des années que j'ai pas programmé). La copie a bien lieu, mais ça ne m'affiche rien. Du coup je suis passé à fopen. Au passage, le fichier temporaire est effectivement bien formaté. Mon tableau que je reçois, c'est le premier, et dans la réalité, il n'est pas terminé par une paire de caractères nuls. Et c'est ce tableau-là que je voudrais convertir en wstring et pas le second où c'est inversé. J'ai cru d'abord à un problème d'endianness, mais apparemment pas.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 //OS cible #include <windows.h> //SL #include <iostream> #include <sstream> #include <string> #include <cwchar> #include <cstdio> #include <locale.h> #include <unistd.h> int main(){ //char wc[]={0,0x42, 0,0x43, 0,0xD, 0,0xA, 0,0xD, 0,0xA, 0,0x44, 0,0}; char wc[]={0x42,0, 0x43,0, 0xD,0, 0xA,0, 0xD,0, 0xA,0, 0x44,0, 0,0}; wchar_t ws []= L"WWWWWWWWWW"; //int newstdout= dup(0); //FILE* f=fdopen(newstdout, "wb+"); FILE* f=fopen("tmp.txt", "wb+"); std::wcout<< f<< std::endl; std::wcout<< fwprintf(f, reinterpret_cast<wchar_t*>(wc))<< std::endl; fwide(f, 1); rewind (f); //std::wcout<< // fwscanf(f, L"%ls", ws)<< std::endl; size_t wchars_reading; std::wcout<< (wchars_reading= fread(ws, sizeof(wchar_t), sizeof(wc)/sizeof(wchar_t), f)) << std::endl; ws[wchars_reading]=L'\0'; wprintf(L"%ls\n", ws); //std::wostringstream woss; // woss<<; std::wcout<< L"A"<< ws<<L"E" <<std::endl; fclose(f); return 0; } //

13/05/2012, 18h49
screetch

j'ai regardé et 0 c'est le descripteur de stdin, pas de stdout, honte sur moi. Avec dup(1); ca peut marcher mieux (ca marche sur mon mac mais j'ai pas de windows pour tester cependant)

sinon je n'ai pas compris quel était le nouveau problème, lorsque tu parles du fichier temporaire.
13/05/2012, 19h01
minnesota

C'est pas grave. En tout cas avec dup(1), ça s'affiche, mais la redirection génère le même problème du \r\r\n. Quand je parle de fichier temporaire, je fais allusion au fichier tmp.txt du code source. Il est correctement formaté \r\n.
13/05/2012, 22h21
JolyLoic

Citation:

Envoyé par minnesota

D'abord merci à vous deux.

En effet JolyLoic mais rediriger la sortie vers un fichier c'est juste une option envisageable, comme on le ferait avec n'importe quel programme console.

Je suis d'accord que n'importe quel programme peut avoir sa console redirigée vers un fichier, et que c'est très utile. Par contre, cette redirection est rarement parfaite, et je ne suis pas convaincu de l'intérêt de la perfectionner. Parce qu'un programme vraiment conçu pour être utilisé depuis une console de manière ergonomique utilisera des choses qu'un fichier ne comprend pas (des couleurs, des retours en arrière pour afficher des 'sabliers'...). Mais aussi parce qu'écrire correctement un fichier même purement textuel demande des choses dont une console n'a que faire (fins de lignes, mais aussi encoding, BOM)
15/05/2012, 09h28
minnesota

Oui, disons juste que c'était nécessaire pour moi de lever le doute sur ce problème, que ça arrive avec wcout, c'est pas gênant, l'interface sera purement graphique comme dit précédemment, mais si cela avait concerné toute la hiérarchie IOStream, ça aurait été problématique. ça m'aura fait un peu d'exercice...

P.-S. : Petite question au passage : Est-ce qu'un projet C++ saurait se passer de la CRT ?
17/05/2012, 08h41
minnesota

Re, c'était juste pour dire qu'apparement je suis obliger d'écrire explicitement "\r\n" quand je veux écrire un saut de ligne dans un fichier avec std::ofstream file (même si le fichier n'est pas ouvert en mode binaire)

En plus, std::wofstream n'écrit même pas en Unicode :?

Enfin, c'est pas la joie quoi...