Информация об изменениях

Сообщение Re[6]: строка... от 04.02.2017 12:54

Изменено 04.02.2017 12:57 m2l

Re[6]: строка...
Здравствуйте, uzhas, Вы писали:

U>тут всё просто. обычно именно линуксоиды советуют UTF-8 как супер-формат. их не заботят проблемы на винде (аргумент: "конвертаций всяко мало будет, профайлер бери")

U>а на тебя досье можно собрать, не выходя из дома

Присоединяюсь к совету для кроссплатформенных проектов по возможности работать в utf-8. И пишу это из под win.
Проблемы с перекодировкой для большинства приложений нет: там где есть работа с файловыми операциями идут довольно тяжелые системные вызовы, где конвертация особой погоды не делает. В gui оверхейд перекодировки пользователь не заметит. Для специфичных вещей с интенсивным вводом-выводом можно написать изолированный код с системными строками. При этом перекодировка неизбежна, а строки удобней иметь максимально унифицированные.

ИМХО: относительно utf-16/utf-8, utf-8 предпочтительные не из-за того, что linux, а потому как менее костыльно. Поинт ms дублировать api и делать utf-16 был в фиксированной дли codepoint-ов. Как не парадоксально они делали это ради совместимости. Но по итогам вышло, что сейчас в винде один символ это может быть два байта, а может четыре — тот же utf-8, только кривоватый. В linux-е тоже делали ради совместимости, только api не трогали, а замену ascii --> utf-8 большинство программ не чувствует, так же как переход на многобайтную вариацию utf-16 (не скажу на вскидку как называется этот стандарт) в windows. В итоге у utf-8 меньший оверхейд по памяти и при передачи по сети, а в остальном всё одинаково. Поэтому и желательней использовать utf-8.
Re[6]: строка...
Здравствуйте, uzhas, Вы писали:

U>тут всё просто. обычно именно линуксоиды советуют UTF-8 как супер-формат. их не заботят проблемы на винде (аргумент: "конвертаций всяко мало будет, профайлер бери")

U>а на тебя досье можно собрать, не выходя из дома

Присоединяюсь к совету для кроссплатформенных проектов по возможности работать в utf-8. И пишу это из под win.
Проблемы с перекодировкой для большинства приложений нет: там где есть работа с файловыми операциями идут довольно тяжелые системные вызовы, где конвертация особой погоды не делает. В gui оверхейд перекодировки пользователь не заметит. Для специфичных вещей с интенсивным вводом-выводом можно написать изолированный код с системными строками. При этом перекодировка неизбежна, а строки удобней иметь максимально унифицированные.

ИМХО: относительно utf-16/utf-8, utf-8 предпочтительные не из-за того, что linux, а потому как менее костыльно. Поинт ms дублировать api и делать utf-16 был в фиксированной длине codepoint-ов. Как не парадоксально они делали это ради совместимости. Но по итогам вышло, что сейчас в винде один символ это может быть два байта, а может четыре — тот же utf-8, только кривоватый. В linux-е тоже делали ради совместимости, только api не трогали, а замену ascii --> utf-8 большинство программ не чувствует, так же как переход на многобайтную вариацию utf-16 (не скажу на вскидку как называется этот стандарт) в windows. В итоге у utf-8 меньший оверхейд по памяти и при передачи по сети, а в остальном всё одинаково. Поэтому и желательней использовать utf-8.