Здравствуйте, ksd, Вы писали:
ksd>Текущий проект развивается под Windows и под Linux. Работает с API как юникодным, так и 1-байтовым, а также с HTTP. При этом нужны строки по крайней мере трех видов: старая ламповая asciiz-строка, ее юникодный вариант, UTF-8 и URL-заенкоженная для веба (ну, этого, считаем, пока достаточно), и, соответственно, перекодировки между этими вариантами. При этом, строка должна работать в кернел моде.
Я бы свел все к UTF-8, и перекодировал в другие варианты где-то очень близко к тому месту, которое коммуницирует со внешним миром.
Здравствуйте, ksd, Вы писали:
ksd>Кто как решает похожие проблемы? ksd>Есть ли какая-то чудо строка, подходящая под описанные условия?
надо анализировать проект:
1) бизнес логика
2) взаимодействие с системным API
всяко в проекте либо винды больше, либо юникса =)
в разных подсистемах может ходить своя строка. нужно минимизировать кол-во конвертаций между разными форматами строк.
зоопарк — это естественно, ибо иначе будут избыточные конвертации, плохо влияет на производительность
я как-то работал с проектом с чудо строкой из icu, так вот конверсий было неприлично много. при переходе на std:(w)string стало гораздо шустрее.
опять же способствовала особенность проекта:
1) серверные компоненты
2) бизнес логика не работает с юникодными символами (не текстовый процессор и тд)
3) обращений к системному API мало
icu строки вполне логично видеть в гуевых проектах
Здравствуйте, uzhas, Вы писали:
U>в разных подсистемах может ходить своя строка. нужно минимизировать кол-во конвертаций между разными форматами строк. U>зоопарк — это естественно, ибо иначе будут избыточные конвертации, плохо влияет на производительность
Оно, конечно, плохо влияет на производительность, но только прежде, чем принимать во внимание это соображение, следовало бы удостовериться, что конвертация строк, на фоне других факторов, влияющих на производительность, вносит хоть какой-либо заметный вклад.
А так, с точки зрения упрощения кода, обычно удобнее постановить, что у нас есть единый общесистемный формат строк (например, UTF-8), я все остальные форматы преобразуются в/из него при вводе/выводе.
Конечно, если окажется, что преобразования форматов строк потребляют неприлично много ресурсов, придется изобретать какой-то другой подход. Но скорее всего, не окажется.
И вот как раз именно у этого проекта специфика такова, что простого и удобного решения не существует. Именно в районе интерфейса к main, так же в файловом API юникс и венда катастрофически несовместимы, если надо передавать программе локализованные строки, и использовать их в качестве имен файлов.
Здравствуйте, 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.
Текущий проект развивается под Windows и под Linux. Работает с API как юникодным, так и 1-байтовым, а также с HTTP. При этом нужны строки по крайней мере трех видов: старая ламповая asciiz-строка, ее юникодный вариант, UTF-8 и URL-заенкоженная для веба (ну, этого, считаем, пока достаточно), и, соответственно, перекодировки между этими вариантами. При этом, строка должна работать в кернел моде.
В данный момент используется 2 кастомные реализации строки: одна совсем кастомная, другая на std::string + std::wstring: в классе-обертке по экземпляру, на каждый из которых дублируются все операции. И местами по ситуации std::string или std::wstring. Считаю, что это избыточный зоопарк.
Кто как решает похожие проблемы?
Есть ли какая-то чудо строка, подходящая под описанные условия?
Здравствуйте, Pzz, Вы писали:
Pzz>А так, с точки зрения упрощения кода, обычно удобнее постановить, что у нас есть единый общесистемный формат строк (например, UTF-8), я все остальные форматы преобразуются в/из него при вводе/выводе.
видно, что ты сидишь на гцц и федоре, так что твой выбор в пользу UTF-8 кажется крайне однобоким
у ТС же кроссплатформенный проект (винда + линукс) и какую строчку там выбрать зависит имхо от специфики проекта
Здравствуйте, Pzz, Вы писали:
Pzz>И вот как раз именно у этого проекта специфика такова, что простого и удобного решения не существует. Именно в районе интерфейса к main, так же в файловом API юникс и венда катастрофически несовместимы, если надо передавать программе локализованные строки, и использовать их в качестве имен файлов.
согласен
Pzz>Но большинство проектов, к счастью, не таковы.
ну main обычно побеждают тем, что принимают только цифры и английские буквы (на крайняк, символы из текущей локали) (char* хватает для этих целей)
а вот работа с файлами довольно часто встречается в проектах и тут надо задумываться какими строчками и кодировками пользоваться
Здравствуйте, Pzz, Вы писали:
Pzz>А ты, я смотрю, наблюдательный
тут всё просто. обычно именно линуксоиды советуют UTF-8 как супер-формат. их не заботят проблемы на винде (аргумент: "конвертаций всяко мало будет, профайлер бери")
а на тебя досье можно собрать, не выходя из дома
Здравствуйте, uzhas, Вы писали:
Pzz>>Но большинство проектов, к счастью, не таковы.
U>ну main обычно побеждают тем, что принимают только цифры и английские буквы (на крайняк, символы из текущей локали) (char* хватает для этих целей) U>а вот работа с файлами довольно часто встречается в проектах и тут надо задумываться какими строчками и кодировками пользоваться
Ну смотря, какая работа с файлами.
Одно дело, если мы берем имя файла где-нибудь у операционной системы, и ей же и отдаем, ничего интересного с ним не делая. Тогда удобнее может оказаться использовать нативный для системы формат представления имени. К тому же, сами по себе функции работы с файлами, если нас не устраивает stdio, очень системно-зависимые, так что может есть смысл всю возню с файлами, включая возню с ихними именами, утащить в системно-зависимый уровень.
Другое дело, если мы много работаем с именами файлов, как с данными. Например, если мы пишем веб-бровсер, и должны уметь превращать URLи в имена файлов. Или если мы берем имена файлов из источника, которому не можем доверять, и должны проверять, что все они попадают в разрешенную директорию. Тогда может иметь смысл работать с именами файлов платформенно-независимым образом. И тут бы я хорошо подумал об UTF-8, потому что если мы относимся к именам файлов, как к сочетанию управляющий символов и всех остальных, как оно часто и бывает, то UTF-8 ничем не отличается от ASCIIZ, а с ASCIIZ работать удобно. Но если к этому добавить еще и требование правильно обрабатывать case-sensetivity, то все становится очень сложно, какое представление не выбери (даже в пределах одной платформы, потому что в зависимости от того, что куда намонтированно, может получиться так, что часть пути чувствительна к регистру, а часть нет, причем и и венде и в юниксе, и причем надо учитывать особенности underlying файловой системы в каждом участке пути — в общем, проще пойти и удавиться сразу).
Ну в общем, в сложно случае, имена файлов — очень специфический пример
Здравствуйте, uzhas, Вы писали:
Pzz>>А ты, я смотрю, наблюдательный
U>тут всё просто. обычно именно линуксоиды советуют UTF-8 как супер-формат. их не заботят проблемы на винде (аргумент: "конвертаций всяко мало будет, профайлер бери")
Ну, понимаешь, изначально все системы были написаны так, словно единственный человеческий язык — это американский диалект английского. Поэтому локализация во всех системах сделана, как набор натяжек и компримисов, с мыслью и новую мультикультурную реальность поддержать, и совместимость со старым добрым миром не потерять.
На мой взгляд, те компромисы, которые были выбраны в юниксовском мире, лучше продуманы.
U>а на тебя досье можно собрать, не выходя из дома
На ту часть моей жизни, которую я не считаю нужным скрывать
Здравствуйте, uzhas, Вы писали:
U>icu строки вполне логично видеть в гуевых проектах
В гуевых проектах логично видеть то, с чем работает гуй. То есть, если Qt, то QString, если MFC, то CString и т.д. Но! Только в гуе, в ядре программы по моему опыту все равно надо работать с ICU, если программа работает с текстом или просто хранить в utf-8, если работы с текстом нет. Все что уходит наружу: текст в файлах, сетевое взаимодействие и т.д., только, только utf-8!
