Discussion :

[SKone]

Bonjour,

Pour que mon code soit indépendant de l'encodage des caractères j'ai fait un simple define :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#ifdef EMV_UNICODE
#define EMV_T( x ) L ## x
#else
#define EMV_T( x ) x
#endif

Et pour faire mes assertions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#define EMV_ASSERT( bExpression, ... ) \
eMV::EmvAssert( EMV_T( #bExpression ), EMV_FILE, EMV_LINE, EMV_FUNCTION, EMV_T( ##__VA_ARGS__ ), EMV_T( "" ) ) )

Et en utilisation ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
EMV_ASSERT( uVar >= 0, "Valeur négative... Pas bien !" ); // OK
EMV_ASSERT( bTest ); // Error C2065: 'L' : undeclared identifier

Ce qui est normal puisque le paramètre 5 de mon eMV::EmvAssert c'est EMV_T( ##__VA_ARGS__ ) donc ça donne L.

La solution simple serait de remplacer tous mes EMV_ASSERT( condition ) par EMV_ASSERT( condition, "" ). Mais c'est assez lourd et ça demande beaucoup de changement dans mon code... J'ai essayé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define EMV_T( x ) L ## "" ## L ## x

Mais ça ne fonctionne évidement pas... Puisque pour un EMV_ASSERT sans message, ça donne L""L...

Donc j'aimerais avoir votre avis pour savoir comment vous auriez résolu ce problème sans reparcourir tout le code en ajoutant des "" useless...

Merci

[koala01]

Salut,

A priori, pour un assert, tu n'es même pas obligé de "jouer" avec l'unicode...

En effet, un assert apparait uniquement dans la console, et en mode débug, encore!

L'idée est donc de les laisser aussi simples que possible, en t'assurant "simplement" de fournir une indication qui te permettra de comprendre pourquoi ton programme a asserté.

Si tu places un message non accentué pour indiquer la raison du refus, tu n'en feras pas vraiment une maladie

Par contre, les règles de fonctionnement de l'assert, voir, qui sait, les différents assert possibles, auraient sans doute du être fixés une bonne fois pour toutes au tout début du développement, en tant qu'outil "indispensable" pour t'assurer du respect des différents contrats

Il t'aurait alors appartenu de veiller, au fur et à mesure, à respecter les règles de fonctionnements imposées par l'assert

Ceci dit, en t'aidant d'outils simples (un "rechercher/remplacer dans la solution" éventuellement agrémenté d' expressions régulières), il devrait être possible de changer la forme de tes assert dans l'ensemble de ton projet de manière à rajouter deux double quotes dans les assert qui en ont besoin

Comme les define sont de toutes manières des symboles qui sont convertis avant même que le compilateur ne commence à essayer de voir le contenu du code, tous les fichiers contenant des assert devront quoi qu'il en soit être recompilés, quelque soit la solution envisagée.

Autant donc essayer de tout faire automatiquement

[SKone]

C'est le même principe utilisé pour le log qui peut être disable avec des FLAG...

Donc j'ai une autre question en rapport avec celle-ci :

Que se passe-t-il donc si mon programme tourne sur un PC Japonais alors que je l'ai compilé avec UTC-2 par exemple ? Les sorties seront-il lisible ?

[koala01]

Tout dépendra de toutes façons du jeu de caractères utilisé par la console...

Car, il et clair que, si la console utilise par défaut les caractères japonais alors que ton code entier (et surtout les sorties consoles) est écrit (sont écrites) en latin1, tu risques très clairement d'avoir un résultat surprenant à l'affichage (en dehors de tout processus fournissant une traduction)

Mais il est, de toutes manières possible de choisir le jeu de caractères utilisés par la console

Ceci dit, même en Belgique, il n'est pas rare de voir que tout le code est écrit, purement et simplement, en anglais, même si on propose une interface graphique.

L'idée est que l'on peut alors parfaitement se contenter de la table de caractères ASCII tant que l'on est au niveau du business (avec l'anglais, on n'a même pas besoin des caractères accentués ), que l'interface graphique est fournie, de base, en anglais, bien qu'utilisant un codage souvent multi-byte (UTF ) et que l'on mette en place un système de traduction, qui lui utilisera le codage "adéquat" par rapport à la langue dans laquelle on fait la traduction.

Je travaille pour l'instant pour la SNCB (la société de chemins de fers belges ) et le projet sur lequel je suis est intégralement géré en anglais, depuis les analyses fonctionnelles jusqu'à l'interface graphique affichée par défaut (développée avec Qt).

Mais on fournit des fichiers de traduction pour le francais, le néérlandais et même l'allemand

[SKone]

Dans mon cas je dois faire des sorties de flux dans différent encodage particulier (différent build pas de changement dynamique).
Ce que je fais c'est que j'ai juste une surcharge des flux standard en fonction des flags dans la build.

Ma class eMV::String peut être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
std::basic_string<char, ...>
std::basic_string<std::wchar_t, ...>
std::basic_string<std::char16_t, ...>
std::basic_string<std::char32_t, ...>

Et pareil pour les FileStream, StringStream, ... Avec mes allocateurs etc...

Donc pour les asserts c'est hors de promo (puisque juste pour le dev), mais pour le reste je devrais faire plus attention.

Sinon je suppose que pour changer l'encodage des caractères de la console c'est des fonctions OS ?