Итак, Qt скомпилирован с /Zc: wchar_t- на окнах. Это означает, что вместо wchar_t является typedef для некоторого внутреннего типа (__wchar_t, я думаю), он становится typedef для unsigned short. Самое замечательное в этом заключается в том, что значение по умолчанию для MSVC - это противоположное, что, конечно же, означает, что используемые библиотеки, скорее всего, скомпилированы с wchar_t другим типом, чем Qt wchar_t.
Это не станет проблемой, пока вы не попытаетесь использовать что-то вроде std::wstring в своем коде; особенно когда одна или несколько библиотек имеют функции, которые принимают ее как параметры. Эффективно получается, что ваш код с удовольствием компилируется, но затем не связывается, потому что ищет определения с помощью std::wstring<unsigned short...>, но они содержат только определения, ожидающие std::wstring<__wchar_t...> (или что-то еще).
Итак, я сделал несколько поисков в Интернете и наткнулся на эту ссылку: https://bugreports.qt.io/browse/QTBUG-6345
Основываясь на заявлении Thiago Macieira, "Извините, мы не будем поддерживать построение Qt, как это", я был обеспокоен тем, что исправление Qt для работы, как и все остальное, может вызвать некоторые проблемы и пытаться избежать этого. Мы перекомпилировали все наши библиотеки поддержки с флагом /Zc: wchar_t- и были достаточно довольны этим до тех пор, пока пару дней назад, когда мы начали пытаться выполнить перенос (мы переходим от Wx к Qt), некоторые сериализации код.
Из-за того, как работает win32, и поскольку Wx просто обертывает win32, мы использовали std::wstring для представления строковых данных с намерением сделать наш продукт максимально готовым. Мы провели некоторое тестирование, и Wx не работал с многобайтными символами при попытке распечатать специальные материалы (даже не такие специальные вещи, как символ степени, был проблемой). Я не уверен, что у Qt есть эта проблема, поскольку QString - это не просто оболочка для базового типа _TCHAR, а монстра Unicode.
Во всяком случае, библиотека сериализации в boost скомпилировала части. Мы попытались перекомпилировать boost с помощью /Zc: wchar_t-, но до сих пор наши попытки сказать bjam сделать это остались без внимания. Мы в тупике.
Откуда я сижу, у меня есть три варианта:
-
Перекомпилируйте Qt и надейтесь, что он работает с /Zc: wchar_t. Там есть некоторые доказательства в Интернете, которые другие сделали это, но я не могу предсказать, что произойдет. Все попытки спросить Qt людей на форумах и т.д. Остались без ответа. Черт, даже в этом очень сообщении об ошибке кто-то спрашивает, почему, и он просто сидел там год.
-
Продолжайте сражаться с bjam, пока он не слушает. Прямо сейчас у меня есть кто-то, кто делает это, и у меня больше опыта борьбы с вещами, чтобы получить то, что я хочу, но я вынужден признать, что устал от этого. Я также обеспокоен тем, что я буду использовать эту проблему только потому, что Qt хочет быть c ** t.
-
Прекратите использование wchar_t для чего-либо. К сожалению, мой опыт i18n в значительной степени равен 0, но мне кажется, что мне просто нужно найти право на/из функции в QString (он имеет BUNCH) для кодирования Unicode в 8-байтный и наоборот. Функции UTF8 выглядят многообещающими, но я действительно хочу быть уверенным, что никакие данные не будут потеряны, если кто-то из Zimbabfuckegypt начнет писать на своем родном языке, а документация в QString немного пугает меня мыслью о том, что это может произойти. Конечно, я всегда мог столкнуться с какой-то библиотекой, которая настаивает на том, что я использую wchar_t, а затем возвращаюсь к 1 или 2, но я скорее сомневаюсь, что это произойдет.
Итак, что мой вопрос...
Какой из этих вариантов - мой лучший выбор? Может ли Qt в конечном итоге заставить меня вытолкнуть мои собственные глаза, потому что я решил скомпилировать его с помощью /Zc: wchar_t?
Какое магическое заклинание должно быть усилено для создания с помощью /Zc: wchar_t- и будет ли это причинять постоянный умственный ущерб?
Могу ли я обойтись просто с использованием стандартных 8-битных (ну, "обычных" ) классов символов и быть совместимым/готовым i18n?
Как другие разработчики Qt справляются с этим беспорядком?
