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

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

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

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

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

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

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

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

Продолжайте сражаться с Бджамом, пока он не послушает. Прямо сейчас у меня есть кто-то под этим, и у меня есть больше опыта борьбы с вещами, чтобы получить то, что я хочу, но я должен признать, что довольно устал от этого. Я также обеспокоен тем, что продолжу заниматься этой проблемой только потому, что Qt хочет быть c ** t.

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

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

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

Какое магическое заклинание, чтобы получить повышение, чтобы построить с / Zc: wchar_t- и будет ли это наносить непоправимый моральный ущерб?

Могу ли я обойтись без использования только стандартных 8-битных (ну, в общем, «общих») классов символов и быть i18n-совместимым / готовым?

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