char или wchar_t, ANSI или Unicode?

[Vladiger]

Такой вот вопросик ламерский созрел:

Большинство примеров кода, а так же иходники различных подключаемых библиотек в качестве строк используют обыкновенные однобайтовые массивы char. Двухбайтовые массивы строк wchar_t встречаются реже, но на мой взгляд (ИМХО) более "правильные" если рассматривать с точки зрения языковых поддержек.
Сам я сейчас не то что бы занимаюсь каким либо "серьёзным" проектом, скорее в качестве хобби, просто пишу игру, а в качестве изучаемого образца графического интерфейса разбираю код DXUT от Microsoft DirectX SDK. Вот как раз там все строки в Unicode. Собственно я уже настолько привык, что не вижу особой разницы что char, что wchar_t если речь идет о простых строках которые могут быть Англо-Русскоязычными.

Так вот собственно вопрос (точнее вопрос в комплексе):

1. Стоит ли заморачиваться с двухбайтовым wchar_t, если сама программа (проект) не предусматривает языковых поддержек и является полностью Русскоязычной, либо Англоязычной, либо Англо-Русскоязычной, т.е. все сообщения из обычного набора символов ASCII?

2. Может быть имеет смысл съэкономить ровно половину оперативной памяти при инициализации строк как однобайтовых массивов char?

3. Могут ли возникнуть трудности со строками ANSI с учетом того, что кроме RUS/ENG в проекте никаких языков и символов не используется?

[Пепел Феникса]

1)русский не входит в ASCII.
он входит в ANSI-1251.
и так же помним, что если у пользователя стоит не русская локаль, то будут косяки.(по умолчанию)
2)потратим на преобразовании, все АПИ принимают юникод.
3)дело не в проекте, а в самой винде, скажем немец на своей винде не увидит русского, если анси(скорее всего, но зависит от локали).

[Vladiger]

по поводу 2 (заменить wchar_t на char) - это я пока не решил, просто задумался. Да собственно и время на переделку АПИ это как бы моё время. Да конечно придется повозиться, попыхтеть, но как говорится цель оправдывает средства, если она конечно есть (цель). В моем же случае цель - съэкономить половину оперативной памяти выделяемую под строки, а так же время обработки обнобайтовых символов и двухбайтовых, наверняка тоже сказывается. Ну это ладно, это мелочи...

Больше интересуют как раз 1 и 3 вопросы относительно стандартов и совместимости приложений на разных машинах.

Всё же не совсем понятно: - Если у пользователя не стоит Русская локаль, то какая будет разница в какой кодировке моя программа обрабатывает строки ANSI или Unicode, ведь ни в той ни в другой у пользователя не установлена локаль cp1251 или UTF8...

Тут я что то запутался совсем. Ведь пользователь не только не увидит Русские символы, но и не сможет их ввести с клавиатуры, так же как я наприер не могу ввести Китайские... А ведь для программы то по сути без разницы в какой они кодировке если она знает что Русский символ "А" имеет код 0xC0 в кодировке ANSI и 0x0410 в Unicode... От меня как от разработчика требуется только определиться, либо А=0xC0 либо А=0x0410...

Сейчас вот погуглил немного, не нашел подходящего материала что бы подробней ознакомиться с выбором символьных кодировок при написании программ, но в некоторых местах все же попадались подобные дебаты и они были как ни странно в пользу однобайтовых char. Встречалось даже умозаключение что wchar_t - это вообще тупиковая ветвь развития.
Но разумеется это все не панацея, это всего лишь мнения людей (програмистов)...

Так что я сам сейчас в тупике. Вроде делаю все правильно, wchar_t, а самого мучает вопрос: - А зачем?

[waleri]

При пользовании уникодом локаль не имеет значение для ввоода/вывода. Главное, чтоб шрифт, коим пишется текст имел нужные символы.
Локаль собственно нужна для неуникод программ, чтоб система знала как переводит уникод символы в 8 бит.

Иными словами, у меня вот нет китайской клавиатуры, т.е. писать я не смогу, но все равно, если надо, увижу иероглифы.

[Пепел Феникса]

Всё же не совсем понятно: - Если у пользователя не стоит Русская локаль, то какая будет разница в какой кодировке моя программа обрабатывает строки ANSI или Unicode, ведь ни в той ни в другой у пользователя не установлена локаль cp1251 или UTF8...

локаль задает конвертирование из анси(причем какое именно анси локаль и решает) в юникод по умолчанию.
обработать вы можете как угодно, вы можете даже все время работать с анси, но ради вывода перевести руками в юникод указав какое анси у вас.
кстати, UTF8 не является двухбайтовой кодировкой.(в винде используется UTF16 в основном, и то её UCS2 часть).

Да собственно и время на переделку АПИ это как бы моё время.

АПИ не ваши и вы не переделаете их.
это система вам дает их.
скажем есть CreateFileA и CreateFileW, первая анси вторая юникод, но при вызове первой произойдет следующее, она переведет строку в юникод и передаст её второй, и все.
и так далее.

Тут я что то запутался совсем. Ведь пользователь не только не увидит Русские символы, но и не сможет их ввести с клавиатуры, так же как я наприер не могу ввести Китайские... А ведь для программы то по сути без разницы в какой они кодировке если она знает что Русский символ "А" имеет код 0xC0 в кодировке ANSI и 0x0410 в Unicode... От меня как от разработчика требуется только определиться, либо А=0xC0 либо А=0x0410...

при обработке да, но лишь.
скажем в одной кодировке 0xC0 это A, а в другой это └.
если при неверной локали пользователь увидит второе вместо первого, это будет не ахти.
при юникоде нужен лишь нужный шрифт.
так и с путями, система тоже не поймет намерений при неверной кодировке или же имя выйдет кривое(Феникс как пример с моей системы, когда стояла не русская локаль)

Сейчас вот погуглил немного, не нашел подходящего материала что бы подробней ознакомиться с выбором символьных кодировок при написании программ, но в некоторых местах все же попадались подобные дебаты и они были как ни странно в пользу однобайтовых char. Встречалось даже умозаключение что wchar_t - это вообще тупиковая ветвь развития.

надо не путать типы данных и кодировки, UTF8 скажем минимальна по размеру считается, но в работе не очень уютна(символ занимает от 1 до 8 вроде байт).
с анси кодировками, где в основном символ это один байт.
юникод не тупивая ветвь развития, а как раз верный путь, когда символ всегда символ нужный, вне зависимости от погоды на марсе.
(видел кучу приложений что не могут понять русский и тп)

[Nuklon]

Vladiger, используй UNICODE вся апи на нём работает, а когда используется ANSI строка функция сама переконвертирует в UNICODE при этом память для преобразования выделяется из кучи, так что быстродействие UNICODE на лицо не надо лишних аллоков и повторного вызова уже настоящей UNICODE функции.
И вообще почему не используешь переопределённый тип TCHAR хедер(tchar.h), дефайнами UNICODE _UNICODE включил/выключил.

[Vladiger]

Пепел Феникса, Nuklon, спасибо друзья, Вы меня наставили на путь истинный!

Да вообщем то я и не решился перестраиваться с wchar_t на char. Так прост, задался вопросом "а зачем это все?"...

И вообще почему не используешь переопределённый тип TCHAR хедер(tchar.h), дефайнами UNICODE _UNICODE включил/выключил.

TCHAR может быть не очень удобен визуально при написании программи, где используются смешанные типы и char и wchar_t в зависимости от операций.
Приведу пример: - Обычные строки сообщений, путей, имен и.т.д. двухбайтовые wchar_t, а часть каких то данных извлекается из текстового файла ANSI (например INI файл). Значит читать конфигурацию из INI файла я буду в char, затем полученные данные по мере надобности переводить в wchar_t при помощи MultiByteToWideChar(). Спрашивается: - А почему INI файл в ANSI? Опять таки для экономии размера файлов и места на диске.
Предопределенный тип в этом случае будет неуместен, ибо мне как разработчику очевидно что я работаю с фиксированными типами данных и что бы самому не запутаться с решениями компилятора каким типом данных он будет определять тот или иной строковый массив, гораздо нагляднее (и на мой взгляд удобнее) инициализировать в программе такие же фиксированные типы char или wchar_t...

Или вот ещё пример: - Предположим наша программа это он-лайн клиент, игра по сети, которая включает в себя обмен текстовыми сообщениями, в чате, в PM и.т.д... При этом это не просто крестики-нолики, а какой то 3D шутер, где в качестве данных передается много параметров, таких как координаты рядом находящихся игроков, их положение, никнеймы и.т.д и.т.п... и все это непрерывно передается пакетами по сети. Естественно для обеспечения высокой скорости передачи, задумаешься о том как на этоих данных можно экономить? Можно их сжимать до передачи и распаковывать после получения, можно 8 булевых параметров побитово запихать в один байт, так же и со строками, передавать не по 2 байта, а по одному. Экономия в глобальном плане не значительная, а вот при передаче по сети очень существенно увеличивает скорость передачи...


2 байта против 1-го, ну это ладно, фиг с ними. Если это идет только на ползу, пускай будет так. В пределах локальной машины, с оперативкой как минимум 1Гб и HDD как минимум 200-500 Гб экономить пару десятков килобайт - ну смешно как то, хотя и рационально!

PS Вообщем примерно суть для себя выяснил. Unicode - это правильно, но много!

[Пепел Феникса]

А почему INI файл в ANSI? Опять таки для экономии размера файлов и места на диске.

неа, ини существуют еще до прихода юникода.
xml например применяет utf8 обычно. там уже идет и универсальность и экономия(хотя преимущество в utf8 в основном то что нет проблем с порядка байт)

Или вот ещё пример: - Предположим наша программа это он-лайн клиент, игра по сети, которая включает в себя обмен текстовыми сообщениями, в чате, в PM и.т.д... При этом это не просто крестики-нолики, а какой то 3D шутер, где в качестве данных передается много параметров, таких как координаты рядом находящихся игроков, их положение, никнеймы и.т.д и.т.п... и все это непрерывно передается пакетами по сети. Естественно для обеспечения высокой скорости передачи, задумаешься о том как на этоих данных можно экономить? Можно их сжимать до передачи и распаковывать после получения, можно 8 булевых параметров побитово запихать в один байт, так же и со строками, передавать не по 2 байта, а по одному. Экономия в глобальном плане не значительная, а вот при передаче по сети очень существенно увеличивает скорость передачи...

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