Le term va très bien, je vis avec cette horreur (oui, il est horrible ce term) avec les autres langages et 36 compilos, et j'en ai eu des problèmes avec lui (car par défaut il n'est pas UTF-8 mais "à l'ancienne" façon Linux avant UTF-8, et du coup il a du mal si je m'amuse avec des caractères qui ne sont pas sur la locale de l'OS utilisé (la locale change suivant la région) alors que j'ai des caractère d'un autre endroit (fichier, réseau etc, la j'en chie bien car du coup je n'ai pas la même locale en input et output, et je dois configurer la local de sortie du coup).
Bref, non, faudrait arrêter d'accuser le term : ici, je teste un input et un output du même term avec donc la même locale, la même configuration. Comme le dit BFG, c'est sans doute un bug de writefln qui ne gère pas de la même manière que le "readfln" (je sais pas comment l'appeler pour l'input) sur un même term, ce qui est un bug (désolé, mais ça me fait bizarre que deux fonctions n'utilisent pas la même façon de se configurer pour un même term). Ce qui me fait peur, c'est que l'OS utilisé n'est pas un OS ayant une part de marché ridicule. Avoir ce genre de bug est rédhibitoire pour moi. Alors, la chance sous Linux est sans doute que writefln écrit du UTF-8 quoi qu'il arrive et que par hasard, et seulement par hasard, vous êtes en UTF-8, mais si vous n'y êtes pas en UTF-8?
C'est un bug, ça arrive, pas de soucis. Ce qui m'a fait réagir ici est qu'on ne se pose pas la question du tout si ça peut venir du compilo, on fonce direct sur la faute au méchant Microsoft en dédouanant pour sûr le compilo, faudrait pas déconner et se poser des questions.
[^] # Re: Je cherche à comprendre
Posté par Zenitram (site web personnel) . En réponse à la dépêche Le langage D. Évalué à 4.
Le term va très bien, je vis avec cette horreur (oui, il est horrible ce term) avec les autres langages et 36 compilos, et j'en ai eu des problèmes avec lui (car par défaut il n'est pas UTF-8 mais "à l'ancienne" façon Linux avant UTF-8, et du coup il a du mal si je m'amuse avec des caractères qui ne sont pas sur la locale de l'OS utilisé (la locale change suivant la région) alors que j'ai des caractère d'un autre endroit (fichier, réseau etc, la j'en chie bien car du coup je n'ai pas la même locale en input et output, et je dois configurer la local de sortie du coup).
Bref, non, faudrait arrêter d'accuser le term : ici, je teste un input et un output du même term avec donc la même locale, la même configuration. Comme le dit BFG, c'est sans doute un bug de writefln qui ne gère pas de la même manière que le "readfln" (je sais pas comment l'appeler pour l'input) sur un même term, ce qui est un bug (désolé, mais ça me fait bizarre que deux fonctions n'utilisent pas la même façon de se configurer pour un même term). Ce qui me fait peur, c'est que l'OS utilisé n'est pas un OS ayant une part de marché ridicule. Avoir ce genre de bug est rédhibitoire pour moi. Alors, la chance sous Linux est sans doute que writefln écrit du UTF-8 quoi qu'il arrive et que par hasard, et seulement par hasard, vous êtes en UTF-8, mais si vous n'y êtes pas en UTF-8?
C'est un bug, ça arrive, pas de soucis. Ce qui m'a fait réagir ici est qu'on ne se pose pas la question du tout si ça peut venir du compilo, on fonce direct sur la faute au méchant Microsoft en dédouanant pour sûr le compilo, faudrait pas déconner et se poser des questions.