striiiiiiiiiiiiiiing - Page 19

Zerosquare (./540) :
Ah, dire que si les grosses boîtes au début de l'informatique personnelle avaient été chinoises ou japonaises, on aurait jamais eu ces problèmes...

ce n'est pas dit ^^

L'origine de l'ASCII est aussi lié aux limitations du hard...

Je me doute bien qu'on aurait pas eu droit dès le début à un système capable de représenter tous les Kanjis, hein

Mais une frein majeur à l'internationalisation des softs a quand même été le fait que l'anglais a une écriture très simple, et que du coup les américains ont rarement pensé aux problèmes qui peuvent se poser dans les autres langues (caractères accentués, combinaisons de caractères, idéogrammes, sens de lecture, etc.).

Oui je suis bien d'accord

D'un autre côté, si les octets faisaient 256 bits, les PC auraient couté plus cher ^^

va savoir

C'est clair... le nombre de logiciels qui déconnent dès qu'il y a des accents est assez hallucinant
(multicross)

Folco (./529) :
yay, suffit de ça pour écrire la date !

    const time_t t = time(NULL);
    tm *s = localtime(&t);
    std::cout << s->tm_mday << "/" << s->tm_mon + 1 << "/" << s->tm_year+ 1900 << std::endl;

Ce format codé en dur ne sera pas compris correctement aux USA…

Folco (./530) :
Tiens, je me pose une question, c'est le topic de Bob qui me fait penser à ça...

int main(int argc, const char **argv)
c'est bien joli, mais quelque soit l'encodage du système, je vais bien récupérer des caractères ascii dans mes char* ?

Pas vraiment, tu auras des caractères 8 bits dans un charset compatible ASCII, mais représentant plus de caractères. Le charset employé dépend du locale, mais dans un OS moderne, c'est l'UTF-8.

Je vais pouvoir les traiter un à un comme des octets ordinaires (ie au sens où j'y suis habitué sur TI) ?

Plus ou moins, il y a quand-même des trucs à éviter avec les chaînes en UTF-8, mais en général c'est assez robuste vis à vis des programmes "cons" (qui le traîtent comme de l'ASCII).

GoldenCrystal (./535) :
int wmain(int argc, wchar_t *argv[]);

Totalement non-standard, cette horreur.
Pourquoi ne peuvent-ils pas utiliser l'UTF-8 comme le reste du monde?

Tu penses que Folco a l'intention d'exporter ses programmes de test aux USA ?

Folco (./544) :
D'un autre côté, si les octets faisaient 256 bits, les PC auraient couté plus cher ^^

quand tu vois que ce n'est que maintenant que les fabriquants de DDs se sont enfin mis d'accord pour passer de 512 à 4096 octets la taille des blocks sur les DDs...

Kevin Kofler (./547) :

Je vais pouvoir les traiter un à un comme des octets ordinaires (ie au sens où j'y suis habitué sur TI) ?

Plus ou moins, il y a quand-même des trucs à éviter avec les chaînes en UTF-8, mais en général c'est assez robuste vis à vis des programmes "cons" (qui le traîtent comme de l'ASCII).

GoldenCrystal (./535) :
int wmain(int argc, wchar_t *argv[]);

Totalement non-standard, cette horreur.
Pourquoi ne peuvent-ils pas utiliser l'UTF-8 comme le reste du monde?

Heuuu... "Le reste du monde" n'utilise pas UTF-8.
UTF-8 est idéal pour l'échange de données (et encore, UTF-16 remplit bien ce rôle aussi), mais pour le reste, c'est complètement sous-optimal, c'est pour ça que "Le reste du monde" n'utilise pas UTF-8...
Les seuls à utiliser UTF-8 de manière native, ce sont les programmes dégeu codés de manière dégueu sous Linux, ce qui inclue ici, et à juste titre de toutes façons, GTK...
Même Qt que tu affectionnes tant n'utilisent pas ce truc impropre à la programmation qu'est UTF-8. Ce qui est tout à fait logique. C'est le choix de JAVA, Windows (à partir de NT avec l'UCS-2), .NET, ... Ceux qui se différencient utilisent UTF-32 (du Unicode brut en quelque sorte) comme c'est le cas avec wchar_t sous linux...
Y'a très peu de trucs sous Windows qui ne gèrent pas l'UTF-8 correctement. (bon, Excel ne veut pas de CSV en UTF-8 par exemple, mais il veut bien les bouffer en UTF-16)
Bref, stop fumer. L'UTF-8 n'est utilisé que dans ta tête (et sur internet ainsi que dans les fichiers texte sur ton disque dur), et bien qu'utilisé par souci de compatibilité, il pose bien plus souvent des problèmes de compatibilités qu'autre chose (cf. topic de Zephyr d'ailleurs).

Mais cherche pas, pour Kevin reste du monde = KDE/Gnu/Linux/Qt

Bon, à nouveau encore un autre souci :
J'ai une classe pour une exception :

class CmdlineException
{
    public:
    CmdlineException(const std::ostringstream & error);
    ~CmdlineException();
    const std::string & getErrorString();

    private:
    std::ostringstream m_errorString;
};

Et dans l'implémentation :

CmdlineException::CmdlineException(const std::ostringstream & error) //: m_errorString(error)
{
}

Et ben quand je décommente la fin de l'implémentation du constructeur, j'ai ça à la compilation :

/usr/include/c++/4.3/bits/ios_base.h|783|error: ‘std::ios_base::ios_base(const std::ios_base&)’ is private|
/usr/include/c++/4.3/iosfwd|52|error: within this context|
/usr/include/c++/4.3/iosfwd|76|note: synthesized method &#x2018;std::basic_ios<char, std::char_traits<char> >::basic_ios(const std::basic_ios<char, std::char_traits<char> >&)&#x2019; first required here |
/usr/include/c++/4.3/streambuf|775|error: &#x2018;std::basic_streambuf<_CharT, _Traits>::basic_streambuf(const std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits = std::char_traits<char>]&#x2019; is private|
/usr/include/c++/4.3/iosfwd|68|error: within this context|
/usr/include/c++/4.3/iosfwd|76|note: synthesized method &#x2018;std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::basic_stringbuf(const std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >&)&#x2019; first required here |
/mnt/Data/Programmation/PC/Anniv/cmdline_except.cpp||In constructor &#x2018;CmdlineException::CmdlineException(const std::ostringstream&)&#x2019;:|
/mnt/Data/Programmation/PC/Anniv/cmdline_except.cpp|11|note: synthesized method &#x2018;std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream(const std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >&)&#x2019; first required here |
/mnt/Data/Programmation/PC/Anniv/cmdline_except.cpp||In member function &#x2018;const std::string& CmdlineException::getErrorString()&#x2019;:|
/mnt/Data/Programmation/PC/Anniv/cmdline_except.cpp|31|warning: returning reference to temporary|

Plein d'erreurs dans les aideurs ! Que se passe-t-il ? Qu'ai-je fait de travers ? Je suis paumé sur ce coup...


Kevin -> non, je ne compte pas exporter ça, c'était un test [nosmile]

Bon, j'ai résoudru mon problème de compilation en passant des string et non des ostringstream. C'est quoi en fait, on peut pas passer des streams comme ça ?

le constructeur de copie de stringstream doit être privé, tu n ^peux pas copier un stream, juste un créer un nouveau et mettre des données dedans avec <<
pourquoi tu veux mettre un stringstream dans ta classe ? ce n'est pas plutot une string que tu veux ?

GoldenCrystal (./550) :
Heuuu... "Le reste du monde" n'utilise pas UTF-8.

Par "reste du monde", je veux dire "tous les autres OS modernes", donc GNU/Linux, OS X, *BSD etc.

UTF-8 est idéal pour l'échange de données (et encore, UTF-16 remplit bien ce rôle aussi), mais pour le reste, c'est complètement sous-optimal, c'est pour ça que "Le reste du monde" n'utilise pas UTF-8...

Euh si, tous les OS modernes à part celui de Redmond (enfin bon, l'appeler "moderne" c'est déjà être gentil ) utilisent l'UTF-8 comme leur charset système (celui du locale) par défaut.

Les seuls à utiliser UTF-8 de manière native, ce sont les programmes dégeu codés de manière dégueu sous Linux, ce qui inclue ici, et à juste titre de toutes façons, GTK...

L'UTF-8 est le charset natif de GNU/Linux, point final. GTK+ utilise le charset du locale en interne, donc il utilise l'UTF-8.

Même Qt que tu affectionnes tant n'utilisent pas ce truc impropre à la programmation qu'est UTF-8. Ce qui est tout à fait logique.

QString utilise effectivement l'UTF-16, surtout pour des questions historiques: quand le support Unicode a été rajouté dans Qt 2, ils ont pris l'UCS-2 qui était à l'époque plus ou moins synonyme de "Unicode" (surtout parce que c'était à longueur constante), et c'est resté parce que ce serait le bordel de porter toutes les applications utilisant QString (en pratique, toutes les applications Qt) vers un QString utilisant autre chose, ils ont juste rajouté le support des surrogate pairs UTF-16 dans Qt 4 (c'était supporté dans une certaine mesure dans les derniers Qt 3, mais Qt 4 est le premier à les supporter pleinement).

Mais ça ne change rien au fait que pour parler aux APIs natives de GNU/Linux, il y a une conversion en le charset du locale qui est normalement l'UTF-8. L'UTF-16 n'est qu'une représentation interne, les entrées-sorties (fichiers, console, autres libs, …) sont en général en UTF-8.

Et ce qui me dérange n'est pas l'utilisation de l'UTF-16 comme charset interne dans W32 et .NET, mais le fait que le locale charset n'est pas Unicode et donc on ne peut pas utiliser les APIs standard et portables sans perdre de l'information. L'intérêt de l'UTF-8, c'est qu'il peut être utilisé comme locale charset de par sa compatibilité ASCII et donc remplacer les charsets non-Unicode obsolètes. Ensuite, je veux bien qu'on utilise l'UTF-16 (Qt le fait aussi), les conversions entre UTF-16 (valide) et UTF-8 (valide) sont sans pertes, donc ce n'est pas trop grave si les 2 sont utilisés, tant que ça reste de l'Unicode. Mais les charsets obsolètes doivent partir et la solution proposée d'abandonner totalement le locale charset (alors que les APIs portables de base l'utilisent, parfois de manière obligatoire (cf. main; wmain n'est pas standard!) et que wchar_t n'est pas une bonne alternative non plus étant donné que même sa taille est variable de système en système) n'est pas du tout pratiquable (du moins dans un programme même un minimum portable), la seule solution viable est de rendre le locale charset Unicode (donc UTF-8, étant donné qu'un char de plusieurs octets causerait le bordel direct).

aze (./554) :
le constructeur de copie de stringstream doit être privé, tu n ^peux pas copier un stream, juste un créer un nouveau et mettre des données dedans avec <<
pourquoi tu veux mettre un stringstream dans ta classe ? ce n'est pas plutot une string que tu veux ?

C'est ce que j'ai fini par faire, c'est plus mieux bien en effet.

GoldenCrystal (./550) :
et sur internet ainsi que dans les fichiers texte sur ton disque dur

En même temps c'est la que c'est le plus important. Le format utilisé en interne, on s'en fout royalement.
Le seul truc c'est de savoir si l'unicode est géré ou non.

Merci, voilà résumé en 2 lignes ce que j'ai dit en 3 paragraphes.

Il n'y aurait pas moyen d'écrire ça en deux lignes ?

            std::string s = "Argument invalide : ";
            s += Arg;

Arg est un char*, et il ne veut pas que j'additionne le char[] et le char*, d'où le fait de construire la chaine en deux lignes. C'est pas grave, mais si vous avez une idée...

folco@Weygand:/mnt/Data/Programmation/PC/Anniv/bin/Release$ ./Anniv ert
Argument invalide : ert
folco@Weygand:/mnt/Data/Programmation/PC/Anniv/bin/Release$ ./Anniv --check
Argument manquand après --check

yaaa, je sais pas quel est l'encodage, mais avec des strcmp, mes comparaisons de chaines dans le programme avec ce qui est passé au prompt marche très bien

std::string s = std::string ("Argument invalide : ") + Arg; ? (mais c'est moins efficace que tes deux lignes ^^)

[edit] j'ai supposé que ta question était "...en une ligne", parceque ton exemple en fait déjà deux ^^

std::string s = QString("Argument invalide : %1").arg(Arg).toStdString();

Anéfé Zephyr, mais en effet, il risque d'y avoir plus de création d'objet dans ton cas, non ? Merci.

Kevin => Non non, je n'ai pas l'opinion de squalyl là-dessus, je me réjouis déjà de l'aide que j'aurai quand j'utiliserai Qt

Folco (./559) :
Il n'y aurait pas moyen d'écrire ça en deux lignes ?

Tu sais, tu n'es pas obligé de passer à la ligne après chaque point-virgule hein

Folco (./562) :
Anéfé Zephyr, mais en effet, il risque d'y avoir plus de création d'objet dans ton cas, non ?

Oui, c'est ce que je voulais dire par "moins efficace"

Okay.

Sally -> Oui, mais lisibilité toussa, j'aime pas trop quoi Je suis donc resté sur mon écriture.

Ce genre de code marche en UTF-8 (j'ai testé) mais foirera en UTF-16/32 / CP1252 ou assimilé ?

        if ((*Ptr >= '0' ) && (*Ptr <= '9'))
        {
            value = (value * 10) + (*Ptr - '0');
            length--;
            Ptr++;
        }

Ce truc marche en tout ce qui est un superset de l'ASCII (donc UTF-8, ISO-8859-*, CP1252, CP437 etc.) si Ptr est un char *, en UTF-16 avec l'endianness de la machine si Ptr est un short * et en UTF-32 avec l'endianness de la machine si Ptr est un int *.

Ok merci donc c'est case gueule. Je ne demande même pas comment on détecte le charset utlisé par le système pour construire l'appel du programme, j'arrêterais immédiatement

Euh au fait, on fait comment pour ouvrir un fichier en son charset natit avec ofstream* ? ça peut pas ?
Je voudrais par exemple, que quand j'affiche un 'é' du fichier sous Linux, j'affiche le même 'é' sous Win ^^

On ne peut pas sans connaître le charset parce que le charset n'est déclaré nulle part (et ne me parlez pas des histoires de BOM UTF-8, c'est une extension issue de Redmond qui est fortement déconseillée par le consortium Unicode (parce que l'UTF-8 n'a pas de "byte order", donc c'est idiot de mettre un "byte order marker"), que personne d'autre n'utilise (et comme la plupart des documents UTF-8 viennent des *nix, ça veut dire qu'ils n'en ont pas) et qui rend les documents incompatibles avec pas mal de logiciels (par exemple GCC donne une erreur si on lui donne un tel fichier à compiler)).