Ajouter un outil personnalisé à toolchain pour supprimer UTF-8 BOM avant la compilation

Question

Ma question est dans le contexte de Code :: Blocks et sa version modifiée de MinGW, et Notepad ++. Je veux être capable d'inclure des littéraux Unicode dans ma source, et je peux le faire, aussi longtemps que j'utilise UTF-8 et n'utilise pas de nomenclature.

Cela fonctionne très bien, jusqu'à un certain point, mais il s'agit d'un mauvais jeu de mots à chaque fois que je rouvre le fichier; il (sans surprise) a cet effet secondaire désintéressant d'afficher l'Unicode dans sa forme ANSI. :(

Ces très utiles et pourtant très ennuyeux trois octets doivent être là, et ils doivent aller! (Au moment de la compilation).

Il semble assez facile, juste prétraiter le fichier source (s) , et rejeter les trois premiers octets (si elles sont une nomenclature UTF-8) ...

Je ne vais certainement pas être le processeur (par suppression manuelle) chaque fois que je compile, donc j'ai même eu recours d'utiliser des fichiers #include sans nomenclature pour ces littéraux, mais cela est problématique à plusieurs points de vue, et non des moindres, c'est que c'est une souffrance proverbiale, et je ne peux pas les "voir"! de jonglerie

Y a-t-il un moyen de puiser dans la chaîne d'outils avec un préprocesseur personnalisé? ... ou si j'ai manqué une solution évidente, j'apprécierais beaucoup d'en entendre parler.

Answer 1

J'ai creusé un peu plus autour, et j'ai trouvé une solution provisoire. Je ne suis pas complètement content car cela implique de modifier la source, alors que je cherchais réellement une solution canalisée, mais il semble que g ++ .exe n'accepte que les arguments en ligne de commande (corrigez-moi si je me trompe).

Ma "solution" est un peu rude et prête, mais ça marche, et c'est certainement mieux (pour moi) que toute autre solution viable que j'ai rencontrée (qui n'en a pas!) Elle nécessite une attention particulière payé à la boîte de message "Fichier a été modifié en externe" de votre éditeur (si le fichier est en cours d'édition), mais en fait, la nomenclature est toujours dans l'éditeur, donc c'est un peu discutable.

Il s'agit d'un simple hack de ligne de commande. Je préférerais une option plus intégrée, mais voici celle-ci (et cela fonctionne):

Dans les blocs de code, allez dans: Paramètres -> Compilateur et débogueur -> Autres paramètres -> [Options avancées] -> Macro de ligne de commande:

Modifiez ces mods sur la ligne de commande. Ils devraient tous être sur une seule ligne (bien sûr), mais pour plus de clarté, je les ai séparés sur:

cmd /c DropTheBOM.exe $file 
& $compiler $options $includes -c $file -o $object // (use your compiler cmdline) 
& MakeTheBOM.exe $file 
// Write your own utils, or try here: http://code.google.com/p/utf-bom-utils/ 

PS: les fichiers #include ne sont pas stripiped de leur nomenclature (si elles ont un) .. Un simple commutateur BOM y/n arg pour la routine #include ces fichiers résoudrait ce problème assez simplement ... (mais c'est seulement un problème de Windows ... c'est peut-être pourquoi ça n'a pas été pris en compte ...

Answer 2

Vous pouvez envisager d'externaliser tous vos littéraux de chaîne dans un fichier séparé de toute façon et en utilisant une fonction loadLit() (ou similaire) pour les obtenir au moment de l'exécution

Cela vous permettra d'avoir un seul fichier (avec une nomenclature) contenant tous vos littéraux de chaîne et vous rendra la vie beaucoup plus facile si vous avez besoin d'internationaliser votre application.Nous faisons cela avec nos trucs mais gardez à l'esprit que nos programmes de classe 1 doivent être conçus pour 21 environnements différents, donc nous économisons beaucoup de travail de cette façon :-) Votre kilométrage peut varier.