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

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

Каша у тебя в голове. В юникоде всё норм.

Дефолтна обычная арифметика.

Ваще ни разу. Это лишь особенность реализации.

Алсо, если ты будешь с помощью float считать деньги, например, я лично приду и сломаю тебе руки куском арматуры.

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

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

Ваще ни разу. Это лишь особенность реализации.

Без «import decimal» не работает. Это сторонняя библиотека. Под капотом которой своё. Так можно на любую стороннюю библиотеку ссылаться. В то время как в языке из коробки другое.

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

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

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

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

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

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

с помощью 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. Плюс, некоторые библиотеки имеют сишный код.

посмотрел, он сделал функцию майн на сях

#include <Rts.h>
extern StgClosure ZCMain_main_closure;
int main(int argc, char *argv[])
{
 RtsConfig __conf = defaultRtsConfig;
 __conf.rts_opts_enabled = RtsOptsSafeOnly;
 __conf.rts_opts_suggestions = true;
__conf.keep_cafs = false;
 __conf.rts_hs_main = true;
 return hs_main(argc,argv,&ZCMain_main_closure,__conf);
}

Всё можно, но не всё нужно. Гарантию точности вычислений дают только целые числа. Арифметика чисел с плавающей запятой даёт погрешности. Да, можно писать дополнительные библиотеки, но под капотом у них будет именно целочисленная арифметика. А её можно заюзать и без дополнительных библиотек.

Си ушел в ембедед и системные штуки

Никуда он не уходил. На C/C++ продолжают писать те же браузеры и офисы. И кучу другого десктопного софта тоже. Просто они теперь чаще всего вагон и тележку сторонних библиотек используют. Но это зависит от масштабов проекта.

И тут вина не юникода совсем.

Создатели юникода усложнили всё введением «кодепоинтов». Если бы они их не вводили бы и один символ/глиф кодировался бы одним кодом, то wchar_t* решал бы все проблемы. А так он решает только половину проблем.

Тебе Альт платит за шизофазирование на ЛОР что ли?

Создатели юникода усложнили всё введением «кодепоинтов».

Тогда пространство юникода давно бы кончилось.

Если бы они их не вводили бы и один символ/глиф кодировался бы одним кодом, то wchar_t* решал бы все проблемы. А так он решает только половину проблем.

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

почему в других языках нет такой проблемы?

Как нет? Выше, например, был приведён действительно рабочий пример с получением длины юникодной строки только в Rust'е. В том же Python'е с этим не справляются ни len(), ни wcwidth.wcswidth() (хотя для ряда данных результаты корректные; но не для всех данных, да).

рабочий пример с получением длины юникодной строки

Я тебе уже в 5 раз пишу тут: для юникодных строк понятие длины зависит от контекста. Это может быть, как минимум:

• Количество байт
• Количество кодпоинтов
• Количество глифов
• Количество печатаемых символов

Мы тут уже не первую страницу обсуждаем получение кол-ва печатаемых и непечатаемых символов. Т.е., по сути:

• Кол-во того, что занимает ровно один кодепоинт, включается в итоговую сумму. Даже если это невидимые символы или табуляция.
• Составные символы из нескольких кодепоинтов составляются и тоже считаются.

Т.е. речь о полном аналоге того, как функции типа len() работали во времена однобайтных кодировок.

Т.е. речь о полном аналоге того, как функции типа len() работала во времена однобайтных кодировок.

И ещё раз напишу тебе: для юникода нет полного аналога функции len() для однобайтовых кодировок. Просто нету. Прекрати уже эту шизофрению тут всем нести.

Так это Вы раскритиковали Си, что у меня в нём такого нет даже через wchar_t*. Перечитайте обсуждение выше.

Так это Вы раскритиковали Си

Ну, да, потому что C – довольно говняный язык.

у меня в нём такого нет даже через wchar_t*. Перечитайте обсуждение выше.

Ты перечитай то, что тебе написали. wchat_t – днище и его надо закопать и забыть как страшный позор. Для C таки есть библиотеки для работы с юникодом. Просто это не стандартная библиотека.

Вот, прямо от создателей юникода: https://icu.unicode.org/

C – довольно говняный язык

Вы просто не умеете его готовить.

Вы просто не умеете его готовить.

Его сишники не умеют готовить в первую очередь.

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

а что там есть сейчас(вообще, не только 8051)? был вроде ivory, но давно не обновлялся

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

а что там есть сейчас(вообще, не только 8051)? был вроде ivory, но давно не обновлялся

Ivory странный. По сути, C натянутый на eDSL в хачкелле. И всё ради «Ivory does not allow nullable pointers, unbounded memory access, or heap allocation». Ну то есть, я могу себе представить, где это нужно, но лучше что-то ещё взять.

А так, из опенсорсного есть Copilot для софта и Clash для FPGA. Второй особенно прекрасен.

Насколько я понимаю из общения с хачкеллотусовкой, каждая контора делает свой eDSL и не особо желает им делиться, потому что бабло :)

Никуда он не уходил. На C/C++ продолжают писать

На C++ продолжают, да.

Кстати есть char32_t, если уж ковыряться с юникодом, можно явно задать ширину кодпоинта, чтобы улучшить переносимость.

Кстати есть char32_t, если уж ковыряться с юникодом, можно явно задать ширину кодпоинта, чтобы улучшить переносимость.

s/есть/будет в c23/

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

Угу. Адекватные люди это понимают. Но на лоре достаточно неадекватов, которые орут, что ничего кроме Си ненужно. Попробуй им объяснить, что писать pdf ридер в машинных кодах нет смысла

хранить mpi рядом, покупка ceil, продажа floor, разницу в карман, делов то. А то пойдут потом инкременты по 0.000375 и будете тоже костыли прикручивать

а деноминатор в uint64 конечно сильно