Подтвердить что ты не робот

С++ тип проекта: unicode vs multi-byte; за и против

Мне интересно, что сообщество Qaru думает, когда дело доходит до создания проекта (в основном, здесь С++) с помощью юникода или многобайтового набора символов.

  • Есть ли профи к Unicode прямо с самого начала, подразумевая все ваши строки будут в широком формате? Существуют ли проблемы с производительностью/большие из-за стандартное использование более крупного символа?

  • Есть ли преимущество в этом методе? Некоторые архитектуры процессоров лучше обрабатывать широкие символы?

  • Есть ли причины, по которым проект Юникод, если вы не планируете поддержка дополнительных языков?

  • Какие существуют причины для создания проекта с многобайтовым набором символов?

  • Как все вышеперечисленные факторы сталкиваются в условиях высокой производительности (например, в современной видеоигре)?

4b9b3361

ОТВЕТЫ

Ответ 1

Два вопроса, о которых я бы прокомментировал.

Во-первых, вы не указываете, на какой платформе вы нацеливаетесь. Хотя последние версии Windows (Win2000, WinXP, Vista и Win7) поддерживают как многобайтовые, так и Unicode-версии системных вызовов с использованием строк, версии Unicode быстрее (многобайтовые версии являются оболочками, которые конвертируются в Unicode, вызывают версию Unicode, а затем конвертируют любые возвращенные строки обратно к mutlibyte). Поэтому, если вы делаете много таких вызовов, Unicode будет быстрее.

Просто потому, что вы не планируете явно поддерживать дополнительные языки, вам все равно следует рассмотреть возможность поддержки Unicode, если ваше приложение сохраняет и отображает текст, введенный пользователями. Просто потому, что ваше приложение является многоязычным, из этого не следует, что все его пользователи будут также иметь язык. Они могут быть очень рады использовать ваш графический интерфейс на английском языке, но могут захотеть ввести имена, комментарии или другой текст на своем родном языке и правильно отобразить их.

Ответ 2

Короткий ответ (IMO, и я был не прав) заключается в том, что лучше планировать худшее (или лучше всего в зависимости от вашей точки зрения) и делать unicode прямо сейчас.

Если ваше приложение не очень интенсивно, то переход к unicode не имеет особого значения; в случае игр это не должно быть большим фактором по сравнению с остальной частью двигателя.

Макс.

Ответ 3

Вы говорите о настройке проекта VС++ здесь, правильно?

Единственное, на что это влияет, - это версия API-интерфейсов Win32, которая заканчивается тем, что она вызывается. Например, вызов MessageBox будет завершен как вызов MessageBoxA в случае многобайтовой настройки и MessageBoxW в случае установки Unicode. Конечно, это повлияет и на типы строковых параметров на эти функции. Внутри MessageBoxA вызывает MessageBoxW после преобразования параметров строки из текущего языкового стандарта системы в Юникод.

Мой совет - использовать настройки Unicode и передавать строки Unicode на вызовы API Win32. Это не мешает вам использовать строки в любой другой кодировке внутри.

Ответ 4

Здесь простое соображение: должна ли ваша программа работать, если она используется г-ном 菅 直 人? Его домашний каталог может быть трудно представить в ASCII.

Ответ 5

Есть ли какие-либо плюсы для перехода в Юникод с самого начала,

Через несколько лет и миллион строк кода вы захотите, чтобы вы ответили "да".

подразумевая, что все ваши строки будут в широком формате?

Я бы хотел, чтобы Microsoft отказалась от объединения Unicode с UTF-16.

Вам не нужно хранить все свои строки в широком формате. Вместо этого вы можете использовать UTF-8 и получить меньший объем памяти (для языков латинского алфавита) и обратную совместимость с 7-разрядным ASCII.

Единственным недостатком использования UTF-8 в Windows является то, что он не поддерживается как кодовая страница ANSI, поэтому вам нужно преобразовать свои строки в UTF-16 для совершения вызовов WinAPI. Сколько неудобств это вызывает, зависит от того, пишете ли вы программу Windows или программу, которая просто запускается в Windows.