Post by Xavier RochePost by Jean-Marc DesperrierSous Windows XP le support des seizet d’indirection (surrogates) est
activé automatiquement, sous Win2000, il suffit de modifier une entrée
de la base de registre.
Oulah. C'est activé pour tous les programmes ?! Ce serait
potentiellement un gros générateur de bugs, dans la mesure où pas mal de
programmes "coupent" violamment les chaînes de WCHAR sans se préoccuper
de la nature des codes (idem pour wcscat(), wcscpy() etc.. qui doivent
allègrement aliaser sur des copies statiques).
C'est un générateur de bug, mais quand on analyse beaucoup moins qu'on
ne penserait.
Les programmes ne font pas des concaténation ou des copies au hasard au
milieu d'une chaîne, sauf les éditeurs de texte, et là oui, ça va merder
assez sérieusement.
Mais un éditeur de texte lui a de toute façon des problèmes bien plus
complexes à régler pour gérer autre chose que les langues les plus
standards.
Les seizet peuvent donc en réalité être assez transparents pour les
applications et windows l'a démontré à grande échelle.
Post by Xavier RocheLe gros interêt de passer en 16-bit, c'est justement éviter le
cauchemard MBCS. Autoriser les surrogates en UCS2, je vois pas l'interêt
(même pour gagner quelques octets) - autant switcher en 32-bit.
Tu es dans l'erreur.
Aucun programme ne peut dire supporter Unicode en restant sur le
paradigme de "un point de code" = "une unité de texte indépendante".
Avec ou sans seizet, il est *impossible* de couper une chaîne n'importe
où sans générer des problèmes que serait-ce qu'à cause des diacritiques.
Donc soit un programme ne fait que transferrer des chaînes, et il n'a
pas besoin de réfléchir en réalité, soit il permet à l'utilisateur
d'éditer ces chaînes, et dans ce cas, l'édition correcte (déplacement du
point d'insertion, suppression du bon bloc quand on fait delete) est
très complexe dès qu'on veut gérer tous les cas correctement, et il
ferait mieux de déléguer ce travail à un composant séparé (une librairie
de localisation sous forme de librairie dynamique qu'on pourrait mettre
à jour indépendamment), car il se lance dans quelque chose de toute
façon voué à l'échec.
Post by Xavier RochePost by Jean-Marc DesperrierEn comparaison, cela demande généralement plus de travail d'en activer
le support sous Linux.
Ben quel interêt ? Si on travaille en mode UCS4 avec des wchar
(sizeof(wchar_t) == 4 sous Linux), les surrogates sont normalement
interdits (c'est quelque part dans la norme), tout comme en UCS2 (sinon
c'est de l'UTF-16). De même, de mémoire, il est interdit d'encoder des
surrogates en UTF-8, et tout ça doit être normalisé à la volée au
besoin, pour avoir de beaux codes complets.
Quand je parlais de support, je parlais d'un affichage graphique, et de
pouvoir les entrer au clavier.
Le fait que wchar est effectivement en général sur 32 bits sous Unix
n'empèche pas les problèmes dès qu'on va plus loin.