Cela permettra de faire facilement des tests de non-régression lors des refactoring.
Je vais donc, en attendant, me concentré sur votre dernière question :
Problème, par exemple :
04/11/2022 et 05/11/2022 [pas-Ó-pas] : Netflix
Pas de solution !
Le début du "problème", c'est à la ligne 65 de votre code.
Vous utilisez des chaines de caractères "en dur" dans cette ligne.
Généralement on évite de le faire pour autre chose que les messages d'erreurs destinés aux développeurs.
En n'utilisant pas de valeur "en dur", cela permet de facilement "localiser" une application (avoir des textes/interfaces qui change en fonction de la langue paramétrée par l'utilisateur de l'application, texte en anglais sur systèmes anglais ou américain, en espagnol sur systèmes espagnol, etc...).
Il y a de multiple "framework" qui permettent de ne pas mettre "en dur" ces textes.
Sous Windows, c'est souvent via des dll de localisation.
Ici, on va peut-être pas mettre toute cette mécanique en branle mais cela explique pourquoi, nativement, on se prend pas trop la tête avec l'encodage des textes dans du code source : généralement, ils ne sont pas dans le code source.
Votre line 65 (et bien d'autres du même acabit) est ambigüe car le code généré sera fonction de pas mal de paramètres, comme le type d'encodage des fichiers sources, la configuration de divers outils dans la chaine de compilation, etc...
Ces ambigüités sont intrinsèques à votre programme, on ne sait pas trop ce que votre programme va envoyer et sous quel encodage aux primitives du système d'exploitation/bibliothèques bas niveau.
Des problèmes de configuration de ces primitives et de configuration de la console qui affichera ces textes peuvent aussi se faire jour.
Pour simplifier la situation, je me mettrais dans une situation "simple" : faire en sorte que mon code source soit en UNICODE-16 (encodage du fichier contenant le code source), que les outils de la chaine de compilation soient configurés pour prendre en entrée les fichiers avec cet encodage.
Une fois ces ambigüités intrinsèques levées, il reste les problématiques de configuration des primitives du système d'exploitation/bibliothèques bas niveau et de configuration de la console.
Pour être sûr de ce qui est envoyé aux primitives du système d'exploitation/bibliothèques bas niveau puis à la console, je vous conseille d'ajouter des traces dans la seule partie qui envoie du texte à la console (donc refactoring du code pour unifier la manière d'écrire dans la console à faire très rapidement).
Dans le code de votre dernier post il semble que cela soit la fonction "Console_Lire" (encore une fois, c'est un nom de MERDE).
Et faire des traces, ce n'est pas polluer la console avec des textes à la con via "std::wcout << ...", comme vous vous obstinez à le faire depuis des mois malgré mes nombreux coup de gueule (cf. votre post du "02/12/2023, 13h56").
Utilisez une MACRO type TRACE ou la fonction "OutputDebugStringW" (attention, fonction non portable) dans le corps de la fonction "Console_Lire" pour que ces traces soient visibles dans la fenêtre "Sortie" de Visual Studio (et dans d'autres outils, si nécessaire).
Il serait peut-être judicieux de permettre le débrayage de ces traces via l'utilisation d'un "#ifdef" par exemple, histoire de ne pas être pollué dans la logue avec ces traces une fois les réglages des configurations (console, bibliothèque bas niveau, etc ...) effectués.
Je vous conseille de logger le texte à écrire mais aussi ce même texte au format hexadécimal pour déterminer "facilement" et de manière univoque l'encodage de ce qui est envoyé.
Une fois cela fait, on pourra voir comment configurer le reste pour qu'ils "comprennent" votre programme.
Partager