Он должен испытать невыносимые муки, мнятно?

И больше чтобы так не делал!

Можно. Одна из возможных стратегий — это внутри программы все строки хранить в UTF-8 (и сохранять в std::string, например). И конвертировать при передаче во внешние API (если это линукс — то либо ничего не делаешь, либо, если хочешь работать по всем правилам, то пробуешь конвертировать в текущую локаль; если это винда — то конвертируешь в UTF-16 перед отправкой в функции типа WriteConsoleW).

ага. с win просто - WriteConsoleA ascii/oem, WriteConsoleW ucs16 (aka utf16)

ага. с win просто - WriteConsoleA ascii/oem, WriteConsoleW ucs16 (aka utf16)

Вот ты написал предложение, и уже стало нифига не просто :) ASCII/OEM (а ещё ведь есть 65001), разница между UCS2 и UTF16 :)

Вот ты написал предложение, и уже стало нифига не просто :) ASCII/OEM (а ещё ведь есть 65001), разница между UCS2 и UTF16 :)

65001 == utf8

Тогда такой вопрос, есть у меня ЮТФ 8 кодировочка в строке, и я ее хочу не вывести а нарисовать

Ну то есть WriteConsoleA — это ANSI, OEM или UTF-8. Поди догадайся.

Как узнать какой символ мне рисовать ?

Как узнать какой символ мне рисовать ?

Шрифтовый рендер знает.

Кстати!

по факту в винде нет utf16, ucs2 как сабсет

А как к нему обратиться ?

Ну то есть WriteConsoleA — это ANSI, OEM или UTF-8. Поди догадайся.

от настроек локали зависит же

Я допустим рисую с помощью openGl

Как узнать какой символ мне рисовать ?

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

А как к нему обратиться ?

Зависит от ОС, от DE, от используемого графического тулкита.

Если ты всё делаешь сам, то фигачь парсер шрифтового формата, и там как-нибудь векторно рисуй потом.

Аааа, эта инфа в шрифте хоронится

Но я бы никому тут не советовал таким заниматься, конечно.

тогда норма, да - все четко вобще

Ну опеджль не умеет в шрифты

Я рисую шрифты сам. И это невыносимые страдания.

и вулкан тоже как следствие

Ну то есть WriteConsoleA — это ANSI, OEM или UTF-8. Поди догадайся.

вообще. писали, что в win10 консоль стала шоколадной c нормальной поддержкой utf8+ и всеми делами. был бы colinux жив, можно было бы заюзать

Я рисую шрифты сам. И это невыносимые страдания.

А почему ? Там ведь просто кубические сплайны внутри

При том, что я ещё использую библиотечные шрифты и рендер, а сам только загоняю это в SVG.

А почему ? Там ведь просто кубические сплайны внутри

Делаю библиотеку для векторного рендеринга LaTeX-формул на одном оффтопном языке.

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

Вспоминаю забавную историю про полнотекстовый поиск в Postgresql на синегальском языке

Вспоминаю забавную историю про полнотекстовый поиск в Postgresql на синегальском языке

Расскажи.

Невыносимые страдания это на вулкане настройку делать :) И потом вспоминать время от времени почему ты сделал так а не иначе. А все остальное, это чистая матеша. Теже шрифты - это просто простые сплайны, без самопересечений, кстати

Расскажи.

Я точно не помню синегальский это был язык или нет, поэтому не буду обманывать.

вообще. писали, что в win10 консоль стала шоколадной c нормальной поддержкой utf8+ и всеми делами. был бы colinux жив, можно было бы заюзать

Я расскажу тебе. 1. Дефолтовая консоль осталась примерно в той же жопе, в какой была. Старые приложения, если они не работали, так и не заработают. 2. Добавили поддержку ANSI-кодов (можно каким-то флагом бинарника включить, вроде) — это работает. 3. В «Windows Subsystem for Linux», вроде как, работает UTF-8. Во всяком случае, я никаких существенных проблем не заметил. Эта подсистема пишет в ту же консоль, но реализация IO там сделана довольно хитро (что для пользовательского кода прозрачно).

Я расскажу тебе. 1. Дефолтовая консоль осталась примерно в той же жопе, в какой была. Старые приложения, если они не работали, так и не заработают. 2. Добавили поддержку ANSI-кодов (можно каким-то флагом бинарника включить, вроде) — это работает. 3. В «Windows Subsystem for Linux», вроде как, работает UTF-8. Во всяком случае, я никаких существенных проблем не заметил. Эта подсистема пишет в ту же консоль, но реализация IO там сделана довольно хитро (что для пользовательского кода прозрачно).

utf* в bash (c) да, работает. в дефолтной консоли осталась одна проблема - copy/paste buffer парсинг

ConEmu эту проблему решает. Во всяком случае, опять же, я давненько не встречал проблем.

вплане консоль ансовая vs u**

А еще в windows wchar_t это шорт, когда везде он инт

Хорошо, когда есть с кем поболтать по душенькам :)

А еще в windows wchar_t это шорт, когда везде он инт

«везде?»

А еще в windows wchar_t это шорт, когда везде он инт

нет

везде это не верно, т.к есть места где он может занимать и 8 бит

Я вот почти наверняка видал контроллеры, на которых это алиас для char.

w == wide

v == vendetta

http://icu-project.org/docs/papers/unicode_wchar_t.html > may be 8, 16, or 32 bits wide (on modern machines), signed or unsigned

Я вот почти наверняка видал контроллеры, на которых это алиас для char.

гм. а где wide всего 8 бит?

Иногда 8 бит это уже шире, чем поддерживает твой character set :)

Иногда 8 бит это уже шире, чем поддерживает твой character set :)

ок. например?

ок. например?

Говорю же, на контроллерах всяких может быть запросто.

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

Говорю же, на контроллерах всяких может быть запросто.

где регистр <8 бит?

Не понял вопрос.

Да, были платформы, на которых регистры были не восьмибитовыми, но как это относится к source character set?

Ты можешь задефайнить, что у тебя charset — это 7-битный ANSI. И тогда восьмой бит действительно будет запасным :)

на каких контроллерах char (не asm reg) может быть меньше 8 бит? мне любопытно

таких не знаю

charset != typeof char

На очень-очень старых. Там в древности были варианты и с 6, и с 9 битами, если не путаю.

На современных, скорее всего, такой дичи нет уже очень давно.

на них си было? если да, то что было с размером sizeof(char)

Ещё были какие-то платформы с 16-битными чарами.

больше может быть, ты говорил про меньше, нет?

Да, говорил.

Ещё были какие-то платформы с 16-битными чарами.

есть даже с 64бит

ERROR: S client not available

на них си было? если да, то что было с размером sizeof(char)

он всегда 1

есть даже с 64бит

Прям 64-битный char? Серьёзно?

на них си было? если да, то что было с размером sizeof(char)

Вон там конкретные примеры приводят: https://stackoverflow.com/questions/2098149/what-platforms-have-something-other-than-8-bit-char

На PDP-10 и каких-то мейнфреймах были 7- и 6-битные чары.

«везде?»

glibc

glibc

glibc имеет альтернативы даже в пределах Linux.

glibc — это ну вообще не «везде».

ну много где

Если честно, мне как раз 32-битные wchar_t кажутся более маргинальными.

Потому, что в POSIX-совместимых программах я их ни разу не видел, да и само устройство POSIX-совместимых ОС не очень-то поощряет их использование.

Все добрые дела там можно делать с помощью ввода-вывода на char. Для wchar_t места почти не находится.

Ну то есть да, там они 32 бита, но ими всё равно почти никто не пользуется, так что (почти) всем пофиг.

Все добрые дела там можно делать с помощью ввода-вывода на char. Для wchar_t места почти не находится.

а если легаси который лень переписывать но он нужен

Есть ещё одна смешная ремарка (на самом деле, грустная). Микрософт почему-то думает, что «Юникод» — это UTF-16LE :)

Так раскрой им глаза!

Так раскрой им глаза!

Выше же обсудили. На самом деле UTF-16LE — это одна из возможных кодировок юникода. Не единственная, и, пожалуй, даже не самая часто используемая.

Выше же обсудили. На самом деле UTF-16LE — это одна из возможных кодировок юникода. Не единственная, и, пожалуй, даже не самая часто используемая.

> и пожалуй, даже не самая часто используемая. и слава богу, она самая бестолковая из них

Спасибо еще раз большое всем за помощь, я сильно продвинулся с таким кодом.

Да ладно, 3 дня на месте топтались

Да ладно, 3 дня на месте топтались

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

Для регулярных выражений лучше boost использовать или что встроенное есть?

Std

Он уже в std

а <regex>

Ага

Только в GCC кажется до сих пор нет

Так что аккуратнее

есть же

Но Бустово это Мэддока,и это хорошо

есть же

Последний раз тв GCC. Было подстава, как я туда смотрел

В 4.8, который в этом долбаном центосе шестом, регексп работает странно