Bonjour a tous,

J'utilise string::size (ou string::length) ppour connaitre la longueur de mon string pour pouvoir faire une mise en page acceptable a l'affichage. Mais je me rend compte que les caractères accentué compte pour deux caractère et donc j'obtiens un décalage d'un caractère. Comment pourraije résoudre cela, sans devoir changer mes caracère accentué par des caractères sans accent.
Si vous avez une idées je suis preneur ;-)

Merci d'avance
Zapp

Bosse en latin1 plutôt qu'en utf-8.

Merci lmghs, je vais essayer. Mais si je fais tourner mon prog sur un autre system qui ne serra pas en latin je vais me retrouver avec le même probleme, ou je me trompe ??

C'est bien ça.
De base, il ne tournera que sous les consoles utilisant des encodages 8-bits.

Hmmmm pas très portable alors. :-(

Mon projet est le programme Cowsay, l'exercice du mois dans ce forum. Je crois que je vais faire une petite boucle qui vas me décompter un emplacement par caractère accentué, ce serra suffisant pour ce programme.

Ou alors ce serrai de retirer les accents avant de compter la longueur de ma chaîne, mais ça devient plus complexe. Je vais faire des essais.

Encore merci a toi lmghs

ps: Si quelqu'un a une autre idée je suis preneur ;-)

Demande à Nanoc comment est sa console.
Les filtres (c'est comme cela que s'appellent les programmes qui transforment des entrées texte en des sorties texte) se posent rarement cette question de l'encodage.

Sinon, j'ai peur qu'il faille une partie non portable de déduction du format d'entrée (et de sortie) afin de correctement encoder en interne les chaines manipulées.

(Je ne peux guère aider, plus, j'ai toujours évité comme la peste ces problèmes d'encodage jusqu'à lors)

Effectivement, tout se passe bien au niveau des filtres, je ressort bien ma chaîne accentuée. C'est juste avec string size que ca déconne, il compte 2 caractères par accentué, puisqu'ils sont codé sur 16 bits au ieu de 8.

Je suis comme toi, j'évite le plus possible ce genre de truc, tout ces encodage différent c'est un casse tète totalement inintéressant. Mais ici je me retrouve dedans sans avoir vu venir. Je crois que je vais tout simplement ignorer le problème pour l'instant et continuer a progresser en C++. J'y reviendrais plus tard. On verra aussi comment les autres on résolu le problème a la fin de cet exercice, ça pourra être très enrichissant.

Alors utilise des wstring. Le calcul des caractères accentués sera fait comme il faut.

Sauf que ce type ne sera pas dispo sous GCC sous windows, et qu'il manquera la conversion stdin (en utf-8 ou en latin1) -> wchar_t à réaliser.
(Si je ne me trompe pas)

M'ouais... j'ai essayer sous windows et VC et ça ne change rien entre un istream et un wistream. Que ce soit du latin1, de l'ansi, du UTF-8 ou du UTF-16.

Il faut donc faire des algorithme de conversion selon ce qu'on attend.

De plus, je me suis souvenu qu'un wchar_t est maximum 16 bits alors que l'utf-8 peut aller jusqu'à 32 bits...

D'où les code convertion facets de boost (planqué au fond de serialize et d'une autre lib), adobe.asl, et je crois bien que cela y sera aussi dans le C++0x.

Quant à la taille de wchar_t ... cela dépend de l'implémentation. Cela existe en 16, 32 comme en 64 bits.

Puisque c'est de moi qu'il s'agit indirectement:
l'encodage de ma console est en utf-8.

Une bonne manière de faire est effectivement d'utiliser boost. Ceci est cependant aller trop loin pour le zéro lambda. Une version qui gère pas les accents ne me pose pas de problème et je crois bien que ttu ne seras pas le seul. De toute façon la gestion des accents dans la console est une vraie plaie.
Mais si tu as envie de coder une version multi-encodage, je dis pas non. Ca m'intéresserait même

Oui j'ai commencé a regarder du coté de boost mais c'est pas encore pour moi, j'ai encore des bases a apprendre, et surtout pratiquer. Et pour une version mufti-encodage je pensais compter les caractère accentué dans ma chaîne et décompter le surplus de string.size mais si les accentué peuvent être codé sur 8, 16, 32 voir 64 bits alors ca devient vraiment un fameux casse tête. Je vais faire quelques essai mais sinon je m'en tiendrai à une version 8 bits, qui est pratiquement finie. J'ai même géré les chaînes sans " ou le fait d'avoir plusieurs arguments, et ça fonctionne bien.

Zapp

Une question que je me pausais en rapport avec ce genre de problèmes,

Serait-il facile et simple de créer une classe "Caractere" qui puisse accepter de l'utf-8 et d'utiliser des "basic_string<Caractere>" à la place de nos "string" habituels ?

Je me demande notemment si en faisant ça on ne se retrouve pas à récupérer des "string" et autres pointeurs de "char" qui nous rendraient la vie difficile.

En faisant ça on pourrait, avec un peu d'héritage, choisir l'encodage utilisé par configuration, ou mieu créer une classe "Caractere" qui reconnaisse d'elle même plusieurs encodages (notemment latin1 et utf-8 dans le cas le plus courant).

Comme vous pouvez vous en douter puisque je pause la question, je n'ai pas encore essayé mais j'avoue que ça me démange depuis un certain temps

De ce que j'ai saisi, ce n'est pas la bonne approche.
(Déjà les types de la SL dépourvu de fonction virtuelle ne sont pas faits pour être dérivés)

Ce qui devrait plutôt être fait, c'est d'imbuer un flux avec un code convertion facet qui sache décoder l'utf-8 vers un type interne, typiquement le wchar_t.
Mais il y a d'autres façons.

Je soupçonne que le mieux est de jeter un oeil aux discussions qui ont dû avoir lieu pour la préparation de la prochaine norme.