Итак, я наконец-то вернулся к своей главной задаче - портированию довольно большого проекта C ++ с Windows на Mac.
Сразу же я столкнулся с проблемой, когда wchar_t имеет 16-битное значение.Windows, но 32-разрядная на Mac.Это проблема, потому что все строки представлены как wchar_t, и между компьютерами Windows и Mac будут передаваться строковые данные в обе стороны (как на дисковых данных, так и в сетевых данных).Из-за того, как он работает, было бы не совсем просто преобразовать строки в какой-то общий формат перед отправкой и получением данных.
В последнее время мы действительно начали поддерживать гораздо больше языков, ипоэтому мы начинаем работать с большим количеством данных Unicode (а также с языками справа налево).
Теперь я мог бы объединить здесь несколько идей и создать для себя больше проблем, чем нужновот почему я задаю этот вопрос.Мы думаем, что сохранение всех наших строковых данных в памяти как UTF-8 имеет большой смысл.Это решает проблему wchar_t, связанную с различными размерами, это означает, что мы можем легко поддерживать несколько языков, и это также значительно сокращает объем используемой памяти (у нас МНОГО - в основном английские - загруженные строки) - но не похоже, что многие люди делаютэтот.Мы что-то упустили?Есть очевидная проблема, с которой вам приходится сталкиваться, когда длина строки может быть меньше размера памяти, в котором хранятся эти строковые данные.
Или использование UTF-16 - лучшая идея?Или мы должны придерживаться wchar_t и писать код для преобразования между wchar_t и, скажем, Unicode в местах, где мы читаем / пишем на диск или в сеть?
Я понимаю, что это опасно близко к тому, чтобы спрашивать мнения - номы нервничаем из-за того, что упускаем из виду что-то очевидное, потому что не похоже, что есть много строковых классов Unicode (например) - но все же есть много кода для преобразования в / из Unicode, как в boost :: locale, iconv,utf-cpp и ICU.