Qt, MSVC и / Zc: wchar_t- == Я хочу взорвать мир

Итак, Qt компилируется с / Zc: wchar_t- в окнах. Это означает, что вместо того, чтобы wchar_t быть typedef для некоторого внутреннего типа (я думаю, __wchar_t), он становится typedef для unsigned short . По-настоящему круто то, что значение по умолчанию для MSVC противоположное, что, конечно, означает, что библиотеки, которые вы используете, скорее всего, скомпилированы с wchar_t , имеющим другой тип, чем Qt wchar_t .

Конечно, это не станет проблемой, пока вы не попытаетесь использовать в своем коде что-то вроде std :: wstring ; особенно, когда одна или несколько библиотек имеют функции, которые принимают их как параметры. Фактически происходит то, что ваш код успешно компилируется, но затем не удается связать, потому что он ищет определения, используя std :: wstring , но они содержат только определения, ожидающие std :: wstring <__ wchar_t ...> (или что-то еще).

Я провел поиск в Интернете и наткнулся на эту ссылку: https: //bugreports.qt.io/browse/QTBUG-6345

Основываясь на заявлении Тьяго Мачейры: «Извините, мы не будем поддерживать такую ​​сборку Qt». Я беспокоился, что исправление Qt будет работать, как и все остальное. может вызвать некоторую проблему, и мы пытаемся ее избежать. Мы перекомпилировали все наши вспомогательные библиотеки с флагом / Zc: wchar_t- и были вполне довольны этим до тех пор, пока пару дней назад не начали пытаться выполнить перенос (мы находимся в процессе перехода с Wx на Qt) некоторой сериализации code.

Из-за того, как работает win32, и поскольку Wx просто обертывает win32, мы использовали std :: wstring для представления строковых данных с целью сделать наш продукт максимально готовым к i18n. Мы провели некоторое тестирование, и Wx не работал с многобайтовыми символами при попытке распечатать специальные данные (даже не такие специальные вещи, как символ степени). Я не уверен, что Qt имеет эту проблему, поскольку QString - это не просто оболочка для базового типа _TCHAR, а своего рода монстр Unicode.

Во всяком случае, библиотека сериализации в boost скомпилировала части. Мы попытались перекомпилировать boost с помощью / Zc: wchar_t-, но до сих пор наши попытки сказать bjam сделать это остались без внимания. Мы в тупике.

С того места, где я сижу, у меня есть три варианта:

1. Перекомпилировать Qt и надеяться, что он работает с / Zc: wchar_t. Там' Есть некоторые доказательства в сети, что это сделали другие, но я не могу предсказать, что произойдет. Все попытки задать вопрос людям Qt на форумах и тому подобном остались без ответа. Черт, даже в том самом отчете об ошибке кто-то спрашивает, почему, и он просто сидел там год.

2. Продолжайте бороться с bjam, пока он не выслушает. Прямо сейчас у меня есть кто-то, кто этим занимается, и у меня больше опыта борьбы с вещами, чтобы получить то, что я хочу, но я должен признаться, что довольно устал от этого. Меня также беспокоит, что я ПОСТОЯНУ буду сталкиваться с этой проблемой только потому, что Qt хочет работать.

3. Прекратите использовать wchar_t ни для чего. К сожалению, мой опыт работы с i18n в значительной степени равен нулю, но мне кажется, что мне просто нужно найти функцию right to / from в QString (у нее есть BUNCH), чтобы кодировать Unicode в 8-байты и наоборот. Функции UTF8 выглядят многообещающе, но я действительно хочу быть уверенным, что никакие данные не будут потеряны, если кто-то откуда-то с более символическим языком начнет писать на своем собственном языке, а документация в QString немного пугает меня, заставляя думать, что это может произойти. Конечно, я всегда мог столкнуться с какой-нибудь библиотекой, которая настаивает на использовании wchar_t, а затем я возвращаюсь к 1 или 2, но я очень сомневаюсь, что это произойдет.

Итак, в чем мой вопрос ...

Какие из них варианты мой лучший выбор? Собирается ли Qt в конечном итоге заставить меня выколоть себе глаза, потому что я все равно решил скомпилировать его с / Zc: wchar_t?

Какое магическое заклинание для ускорения строительства с помощью / Zc: wchar_t- и приведет ли ЭТО к необратимым ментальным повреждениям?

Можно мне обойтись стандартным 8-битным (ну, «обычным» в любом случае) классы символов и быть совместимыми / готовыми к i18n?

Как другие разработчики Qt справляются с этим беспорядком?