По своей программистской природе я очень не люблю неоптимальность и избыточность в коде. И вот, читая в очередной раз на работе исходный код Mail.Ru Агента, вновь наткнулся на одну раздражающую особенность в способе реализации перевода строк продукта на разные языки.
Локализация здесь выполняется довольно нехитро. Все строки, требующие перевода, оборачиваются в макрос _TR():
wprintf(L"%sn", _TR("Some hashing string"));
Макрос возвращает нужную версию текста в зависимости от текущего используемого языка. Определён он следующим образом:
#define _TR(x) g_Translator.Translate(x)
Здесь происходит обращение к глобальному объекту g_Translator, который в функции Translate() считает crc32 от указанной строки и ищет в своей xml-базе перевод с совпадающей контрольной суммой.
Не буду судить насколько такое решение оправдано, но оно проверено временем и показало себя достаточно надёжным. И всё бы ничего, но такое решение не лишено недостатков: по сути, функция делает лишнюю работу — контрольные суммы можно было бы подсчитать один раз на этапе компиляции, и использовать в дальнейшем уже готовые числовые значения. Это также избавило бы от необходимости хранить в исполняемом образе дублирующиеся строки, ведь они уже есть во внешнем xml-файле с переводами.
Немного погуглив по запросу «compile-time crc32» я быстро понял, что задача это не самая тривиальная, а готовых решений мне найти так и не удалось.
Читать полностью »
