Тип проекта C ++: Unicode против многобайтовых; плюсы и минусы
Вот простой пример
from pandas import DataFrame
# Create data set
d = {'Revenue':[100,111,222],
'Cost':[333,444,555]}
df = DataFrame(d)
# mask = Return True when the value in column "Revenue" is equal to 111
mask = df['Revenue'] == 111
print mask
# Result:
# 0 False
# 1 True
# 2 False
# Name: Revenue, dtype: bool
# Select * FROM df WHERE Revenue = 111
df[mask]
# Result:
# Cost Revenue
# 1 444 111
6 ответов
Два вопроса, которые я бы прокомментировал.
Во-первых, вы не упоминаете, на какую платформу вы ориентируетесь. Хотя последние версии Windows (Win2000, WinXP, Vista и Win7) поддерживают как многобайтовые, так и юникодовые версии системных вызовов, использующих строки, юникодовые версии быстрее (многобайтовые версии являются обертками, которые конвертируются в юникод, вызывают юникодовую версию, затем конвертируют все возвращенные строки обратно в многобайтовые). Поэтому, если вы делаете много таких вызовов, Unicode будет быстрее.
Только потому, что вы не планируете явную поддержку дополнительных языков, вам все равно следует подумать о поддержке Юникода, если ваше приложение сохраняет и отображает текст, введенный пользователями. Если ваше приложение является одноязычным, это не означает, что все его пользователи тоже будут одноязычными. Они могут быть совершенно счастливы использовать ваш англоязычный графический интерфейс, но могут захотеть вводить имена, комментарии или другой текст на своем родном языке, и чтобы они отображались должным образом.
Короткий ответ (IMO, и я ошибался): лучше спланировать худшее (или лучшее, в зависимости от вашей точки зрения) и использовать Unicode прямо сейчас.
Если ваше приложение не является очень строковым, переход непосредственно к Unicode не имеет особого значения; в случае игр это не должно быть большим фактором по сравнению с остальной частью движка.
Макс.
Вы ведь говорите о настройке проекта VC ++, верно?
Единственное, на что это влияет, - это на версию вызовов Win32 API, которые в итоге выполняются. Например, вызов MessageBox завершится вызовом MessageBoxA в случае многобайтовой настройки и MessageBoxW в случае настройки Unicode. Конечно, это также повлияет на типы строковых параметров этих функций. Внутри MessageBoxA вызывает MessageBoxW после преобразования строковых параметров из текущего языкового стандарта системы в Unicode.
Мой совет - использовать настройки Unicode и передавать строки Unicode в вызовы Win32 API. Это не мешает вам использовать строки в любой другой кодировке внутри.
Есть ли плюсы в переходе на Unicode с самого начала?
Через несколько лет и миллион строк кода вы будете жалеть, что не ответили "да".
подразумевая, что все ваши строки будут в широком формате?
Я бы хотел, чтобы Microsoft перестала путать "Unicode" с UTF-16.
Вам не обязательно хранить все ваши строки в широком формате. Вместо этого можно использовать UTF-8, получая меньший объем памяти (для языков с латинским алфавитом) и обратную совместимость с 7-битным ASCII.
Единственным недостатком использования UTF-8 в Windows является то, что он не поддерживается в качестве кодовой страницы ANSI, поэтому для выполнения вызовов WinAPI вам придется преобразовывать ваши строки в UTF-16. Насколько это неудобно, зависит от того, пишете ли вы программу для Windows или программу, которая просто работает под Windows.
Первый ответ на этот вопрос должен... ответить на все, что вам нужно знать.
Вот простое соображение: должна ли ваша программа работать, если ее использует г-н 菅 直 人? Его домашний каталог может быть трудно представить в ASCII.