Написал статью «Как жить если у вас юникод»

Как раз таки юникодные функции просят wchar_t*.

Как раз таки юникодные функции просят wchar_t*.

Ты можешь называть их как угодно, юникодными они от этого не стали :D

Впрочем, при внимательном рассмотрении, модификаторы эмодзи wcslen() таки парсит плохо. Поэтому, если надо, её результат придётся подправить.

Ага. А знаешь, почему? Потому в что в выводе man wchar.h нет ни слова про unicode :D

Полноценная работа с текстом - задача не очень простая. Я рекомендую использовать UTF-8 и ознакомиться с библиотекой ICU. Использование wchar_t даёт иллюзию того, что всё просто, но эта иллюзия разбивается о нетривиальные случаи.

Как мы уже выяснили, она разбивается даже о тривиальные :D

Конечно, в юникоде всё нормально. Ведь он сферический в вакууме.

Да нет, он вполне конкретный и существует.

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

Я ничего не понимаю. Что это вообще значит?

Без «import decimal» не работает. Это сторонняя библиотека.

Это не сторонняя библиотека, это часть стандартной библиотеки Python, которая поставляется вместе с интерпретатором. Ты блин ещё libm назови сторонней библиотекой в C.

Ну эмодзи и китайские иероглифы это всё же нетривиальные случаи в моей классификации. Тривиальные это английский и русский алфавиты. Там - да, в целом проблем быть не должно. Хотя там и с KOI8-R всё работает…

Я в русский текст вечно эмодзи сую :D

с помощью float считать деньги

В Паскале для этого есть тип данных Currency, например. В других языках аналог найти сложно, но там проще считать целыми числами в минимальных единицах, т.е. в копейках и центах, например. Потом при отображении результата можно поделить на степени 10 и результат будет точным.

В других языках аналог найти сложно, но там проще считать целыми числами в минимальных единицах, т.е. в копейках и центах, например.

И что ты будешь делать когда расчеты будут в долях цента?

Я ничего не понимаю. Что это вообще значит?

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

Это не сторонняя библиотека, это часть стандартной библиотеки Python

А. Не так посмотрел. Ну, значит, можно и так.

Менять масштаб. Т.е. один цент будет уже не 1, а, например, 1000.

Сишные пердоли даже дробные числа в базу засунуть не могут, вот умора.

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

Потому что юникод покрывает гораздо больше, чем однобайтовые кодировки. И тут вина не юникода совсем. Проблема в том, что человеческая письменность – ад и израиль.

Менять масштаб. Т.е. один цент будет уже не 1, а, например, 1000.

А вот если бы в C была библиотека для работы с десятичными числами…

Причём, запилить её не то чтобы сложно, на самом деле. Просто сишники не могут…

Ладно, на самом деле, их есть и пачка, просто в стандартной библиотеке почему-то нет. В ней вообще нихрена нет.

Основной ад это конверсии. Сделать структуру

struct bablo {
    uint32_t currency_code;
    uint64_t numerator;
    uint64_t denominator;
}

И арифметику сферху не то чтобы рокет сцаенс.

Хотя ладно, там конечно BigInt, кого я обманываю.

В ней вообще нихрена нет

На самом деле и не очень то надо.

Си ушел в ембедед и системные штуки, где задача стоит обычно избавиться от стандартной библиотеки и получить bin а то и hex файл с машинным кодом минимального размера.

Те кому нужны все эти юникоды просто давно уже ушли на другие языки.

Я даже не знаю, как это делать, ну кроме как в гугле найти и скопипасить.

uint64_t numerator; uint64_t denominator;

Нинада так делоц! А то у тебя 3/7 цента вылезет откуда-нибудь и ты запаришься это разгребать.

Работа с деньгами – это довольно фееричная тема, я недавно для этого отдельную библиотечку у нас сделал. Деньги нельзя делить как ты это с числами делаешь, например. Делить в принципе можно, но результатом у тебя будет список из чисел, которые дают в сумме оригинальное число. При этом они не обязательно равны друг другу. Т.е. делается деление с остатком и остаток равномерно размазывается по результатам.

В ней вообще нихрена нет

На самом деле и не очень то надо.

Си ушел в ембедед и системные штуки, где задача стоит обычно избавиться от стандартной библиотеки и получить bin а то и hex файл с машинным кодом минимального размера.

Те кому нужны все эти юникоды просто давно уже ушли на другие языки.

Ты мне щаз хочешь сообщить, что системный софт не должен уметь в юникод? Ты с дуба рухнул, что ли? У тебя имена файлов в какой кодировке?

У тебя имена файлов в какой кодировке

В линуксе - ни в какой. Просто байт-стринг.

Кстати интересная мысль, не думал в таком контексте. К примеру если 10.00 / 3 = 3.33 + 0.01, т.е. при использовании операции деления всегда есть второй результат - остаток. Не видел нигде, чтобы так было реализовано, но мне очень нравится такой подход, утащу на подкорку.

У тебя имена файлов в какой кодировке

В линуксе - ни в какой. Просто байт-стринг.

А на экран ты его выводить тоже байтами будешь?

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

на экран ты его выводить тоже байтами

Это делают всякие файловые манагеры, которые могут быть написаны хоть на питоне. За системный софт не считается :)

Кстати интересная мысль, не думал в таком контексте. К примеру если 10.00 / 3 = 3.33 + 0.01, т.е. при использовании операции деления всегда есть второй результат - остаток. Не видел нигде, чтобы так было реализовано, но мне очень нравится такой подход, утащу на подкорку.

Ты с финансовым софтом поработай. Там у тебя будет как раз [3.33, 3.33, 3.34] как результат специальной функции. А обычного деления для денег просто нет.

на экран ты его выводить тоже байтами

Это делают всякие файловые манагеры, которые могут быть написаны хоть на питоне. За системный софт не считается :)

чо? У тебя эмулятор терминала в самое ядро всунут и даже поддерживает вывод юникода на экран. Куда уж блин системнее ядра?

суёшь в их код текст с эмоджи и прочими непотребствами

Ну это такой ембеддед уровня банкомата на винде с бравзером на полный экран и гигабайтом яваскрипта. В принципе конечно тоже эмбеддед :)

суёшь в их код текст с эмоджи и прочими непотребствами

Ну это такой ембеддед уровня банкомата на винде с бравзером на полный экран и гигабайтом яваскрипта. В принципе конечно тоже эмбеддед :)

Я понял. Ебмеддед – это то, что осилили сишники. А то, что сишники не осилили, это не ебмеддед.

эмулятор терминала в самое ядро всунут и даже поддерживает вывод юникода на экран

Именно поэтому его давно уже оттуда хотят выкинуть.

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

В линуксе - ни в какой. Просто байт-стринг.

А давай проверим:

$ cd src/linux/fs/ext4
$ git grep utf8 .
hash.c:         dlen = utf8_casefold(um, &qstr, buff, PATH_MAX);
namei.c:                ret = utf8_strncasecmp_folded(um, name, &entry);
namei.c:                ret = utf8_strncasecmp(um, name, &entry);
namei.c:        len = utf8_casefold(dir->i_sb->s_encoding,
namei.c:            sb->s_encoding && utf8_validate(sb->s_encoding, &dentry->d_name))
super.c:        utf8_unload(sb->s_encoding);
super.c:        {EXT4_ENC_UTF8_12_1, "utf8", UNICODE_AGE(12, 1, 0)},
super.c:        encoding = utf8_load(encoding_info->version);
super.c:        utf8_unload(sb->s_encoding);

Кажется нет :)

то, что сишники не осилили, это не ебмеддед

почему, тоже ембеддед, но немного другой, без си обычно обходится он)

то, что сишники не осилили, это не ебмеддед

почему, тоже ембеддед, но немного другой, без си обычно обходится он)

Знаешь, вот я читаю это всё и вспоминаю цитату Торовалтоса: «Если бы использование C оградило нас от программистов на C++, это был бы достаточный аргумент чтобы использовать C».

Я вот считаю, что если отказ от использования C ограждает от программистов на C, то это достаточный аргумент, чтобы C не использовать. Потому что большая часть сишников в нынешние времена – какие-то совсем ущербные обезьяны с пюрешечкой вместо мозга. Видимо, все более-менее адекватные либо умерли от алкоголизма, либо ушли на пенсию (и умерли от алкоголизма).

вот зараза, небось вместе с растом всунули :)

хорошо хоть под #if IS_ENABLED(CONFIG_UNICODE)

ущербные обезьяны с пюрешечкой вместо мозга

Вот ты нетолерантен вобще)

Они бывают разные. Си ушел в очень узкую нишу и пока там прочно сидит. Посмотрим как там его потеснит раст и прочие.

Я не то чтобы топлю за Си, но и ненависти к си и сишникам понять не могу)

Они бывают разные. Си ушел в очень узкую нишу и пока там прочно сидит.

Ну как ушёл. Из одних ниш его просто выперли (десктопный софт), в других его никогда и не было (всякая вебня).

Я не то чтобы топлю за Си, но и ненависти к си и сишникам понять не могу)

Си – довольно убогий и всратый недоязычок. А сишники – если мы имеем ввиду тех, кто ничего больше не осилил – это крайне неумные люди.

Я не то чтобы топлю за Си, но и ненависти к си и сишникам понять не могу)

Сишники это парадоксальная история людей, которые получают меньше всех в IT, но при этом пытаются делать вид что они самые востребованные и без них никуда. При этом пишут обычно редкостную срань.

Ну хз, у вас странные сишники и странный опыт общения с ними :)

Я работал но такого не видел, было обычное деление и правила округления.

Си – довольно убогий и всратый недоязычок.

Си это такой более менее человеческий ассемблер.

Пока компы были слабые его пихали везде. Теперь он остался только в системных и мелких встроенных системах. Раст-то на 8051 пока не портировали вроде)

А сишники – если мы имеем ввиду тех, кто ничего больше не осилил – это крайне неумные люди.

В этом утверждении си можно заменить на любой другой язык.

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

Какого хрена «проще», если ты в них даже не сможешь представить тексты, повсеместно встречающиеся в 2K24 году на просторах интернета?

Чтобы общаться со своей шизой тебе не нужен NLS.

Си это такой более менее человеческий ассемблер.

Более-менее человеческим ассемблером он был для PDP-11. К современным процессорам и их ассемблеру C отношения вообще не имеет. Нынешние компиляторы преобразуют код в такую кашу из ассемблера, что мама не горюй!

Раст-то на 8051 пока не портировали вроде

Зато на хачкелле под 8051 писать можно без проблем. Я не шучу, если что.

В этом утверждении си можно заменить на любой другой язык.

Безусловно, но я ни разу не встречал столько спеси среди фанатов JS или пердона.

Безусловно, но я ни разу не встречал столько спеси среди фанатов JS или пердона.

Потому, что они в IT пришли бабло заколачивать, а сишники - делать мир лучше.

Потому, что они в IT пришли бабло заколачивать, а сишники - делать мир лучше.

Благодаря сишникам мы по уши в дерьме. Можно они уйдут уже и перестанут делать мир «лучше»? Пожааааааалуйста!

компиляторы преобразуют код в такую кашу из ассемблера

Но ты же не будешь писать на асме что-то кроме вставок из десятка строк

Тот же ghc компилирует хаскель через си ну и далее как обычно .s, .o, .elf

Тот же ghc компилирует хаскель через си

Нет, не компилирует. Там другой конвейер: Haskell -> Core -> STG -> C— (да, Си Минус Минус) -> Assembler или LLVM

Компиляция через C используется только при портировании самого компилятора на новые архитектуры и по дефолту вообще выключена.

Хз, посмотрел strace-ом, у меня он открывает какие-то .c файлы и дергает /usr/bin/cc

Он вызывает ассемблер и линкер через cc. Плюс, некоторые библиотеки имеют сишный код.