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

сишные пердоли вместо удобной структуры пердолятся перебором по списку

хз, любители си в линуксе обычно берут glib, или какой-нибудь менее известный uthash

хз, любители си в линуксе обычно берут glib, или какой-нибудь менее известный uthash

О нет. Открой исходники какого-нибудь вейланда, там едет список через список.

Открой исходники какого-нибудь вейланда

ну вон пошарился, какие-то хеш таблицы у них есть

https://gitlab.freedesktop.org/wayland/wayland/-/blob/3175e91efa4d4cb1847044f9ea4a8ef57fd6f39c/src/wayland-hash.c

с другой стороны, если у тебя десяток элементов, то перебор наверное м быть проще и быстрее.

Да-да, там все это есть.

Значит, через костыли, а не юникодные функции. Или через сторонние библиотеки наподобие ICU.

Значит, через костыли, а не юникодные функции. Или через сторонние библиотеки наподобие ICU.

Просто никому в голову не приходит использовать непортируемый wchar_t.

Мало линуксоидов. Портируют в свою винду то, что пишут через WSL.

А если линуксоид пишет конкретно под свой GNU/Linux, то проблемы портируемости его не так уж и волнуют.

иного варианта сейчас и нет фактически

HTML же!

А если линуксоид пишет конкретно под свой GNU/Linux, то проблемы портируемости его не так уж и волнуют.

Я понимаю что тебя не очень волнует портируемость твоего софта, потому что его никто не использует. А всех остальных волнует :D

Открой исходники какого-нибудь вейланда

ну вон пошарился, какие-то хеш таблицы у них есть

https://gitlab.freedesktop.org/wayland/wayland/-/blob/3175e91efa4d4cb1847044f9ea4a8ef57fd6f39c/src/wayland-hash.c

с другой стороны, если у тебя десяток элементов, то перебор наверное м быть проще и быстрее.

Удивительно, что в стандартной библиотеке этого до сих пор нет.

И никто не сказал, что шрифт нечитаем.

Алсо эта функция считает не глифы :D

Для строки «Yes 重要» она вернет 8.

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

Я считаю, что софт может быть и для красноглазиков. И нет такой обязанности у софта выходить за пределы одной платформы. Т.е. если мне скажут, что, например, мой софт не собирается во FreeBSD, то это меня не очень огорчит, поскольку у меня и не было такой задачи, чтобы он собирался вне GNU/Linux'а. Собирается - хорошо, не собирается - ну и ладно, я под них и не писал.

Я считаю, что софт может быть и для красноглазиков. И нет такой обязанности у софта выходить за пределы одной платформы. Т.е. если мне скажут, что, например, мой софт не собирается во FreeBSD, то это меня не очень огорчит, поскольку у меня и не было такой задачи, чтобы он собирался вне GNU/Linux’а. Собирается - хорошо, не собирается - ну и ладно, я под них и не писал.

Это прекрасно, только то что ты выше написал не работает.

Для строки «Yes 重要» она вернет 8.

Иероглифы широкие. Каждый из них в ширину занимает 2 знакоместа в консоли. Отсюда и 8.

Т.е., да, как бы, не совсем глифы, но не совсем не глифы. Если выделить место соответствующей ширины для строки, то ошибки не будет.

Удивительно, что в стандартной библиотеке этого до сих пор нет

ну не то чтобы совсем нет

hcreate, hdestroy, hsearch - в POSIX

Т.е., да, как бы, не совсем глифы, но не совсем не глифы

Что за бред я только что прочитал?

Если выделить место соответствующей ширины для строки, то ошибки не будет.

А если мне надо посчитать количество глифов – будет. Короче, перестань делать вид что wchar_t это API для работы с юникодом. Это не так. Это просто артефакт из прошлого который попытались натянуть на Юникод как смогли. Вышло плохо.

Для чего считают глифы? Чтобы выделить соответствующее место на экране. В той же консоли, например.

Вот эта функция и считает сколько знакомест в консоли надо выделить чтобы строка влезла.

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

В общем, везде свои погрешности. Даже «0.1 + 0.2» в Python'е не равно 0.3. И число π до последней цифры мы никогда не узнаем.

Для чего считают глифы? Чтобы выделить соответствующее место на экране. В той же консоли, например.

Чтобы посчитать количеств букв в слове, например :D

Между прочим, wcwidth.wcswidth() в Python'е тоже возвращает 8.

len() возвращает 6, но, как было замечено выше, она не со всем юникодом нормально работает, поскольку не все символы влазят в один кодепоинт. Куча составных.

Удивительно, что в стандартной библиотеке этого до сих пор нет

ну не то чтобы совсем нет

hcreate, hdestroy, hsearch - в POSIX

Только это не хэш-таблица. И не стандартная библиотека языка.

Ух лул…

len() возвращает 6, но, как было замечено выше, она не со всем юникодом нормально работает.

Оно со всем юникодом работает нормально.

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

Даже «0.1 + 0.2» в Python’е не равно 0.3.

Охлолжежтыблин!

 ▲ ~ python
Python 3.10.12 (main, Jun  6 2023, 22:43:10) [GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> Decimal('0.1') + Decimal('0.2')
Decimal('0.3')

И число π до последней цифры мы никогда не узнаем.

Щща.. в Старый Оскол завезут траву по-забористее, и ты нам стопудов последнюю цифру скажешь.

Не так как планировалось изначально в 1990-х. Изначально она возвращала кол-во видимых символов в строке.

Нет не возвращала. Ты ещё блин \t за один символ при выводе на экран начни считать.

Decimal('0.1') + Decimal('0.2')

Костыль как и wcwidth.wcswidth().

Decimal(‘0.1’) + Decimal(‘0.2’)

Костыль как и wcwidth.wcswidth().

Схрена ли десятичная арифметика костыль?

Между прочим, wcwidth.wcswidth() в Python’е тоже возвращает 8.

Конечно возвращает. Потому что в мане этой функции написано вот это:

determine columns needed for a fixed-size wide-character string

Про глифы тут речи вообще не идет.

А я юникод во фрипаскале не осилил.

подожди, ща они юникод в стандарт мож включат, а там лет через 20 и до хешей дойдёт)

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

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

>>> 0.1 + 0.2
0.30000000000000004
>>>

Про глифы тут речи вообще не идет.

А где про них идёт речь?

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

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

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

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

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

А где про них идёт речь?

В моей бизнес-логике, например. Мне надо посчитать скока букв в слове. Твой убогонький wchar_t пока этого сделать не смог.

wchar_t длина гарантирована в один char только ЕМНИП, так что нафига его трогать я так и не понял.

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

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

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

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

Это только тип данных. Какая библиотека в каком языке считает «сколько букв в слове»?

Это только тип данных. Какая библиотека в каком языке считает «сколько букв в слове»?

Я хочу в сях посчитать сколько букв в слове используя utf-8. Жги.

Так это Вы утверждаете, что у Вас всё работает без wchar_t, а у меня с wchar_t не работает.

Вот я и говорю: где хоть один рабочий пример для юникода? Оно вообще бывает в природе? А если не бывает, то о чём тогда речь, при чём тогда wchar_t?

fn main() {
    println!("{}", "重要".chars().count());
}

Покажете тебе 2.

Проблемы могут начаться если возникнет желание портировать этот софт на винду

Но ты же сказал, что wchar_t — кроссплатформенный тип

Так он шизик.

Правильно. Кроссплатформенный. Только его размер на разных платформах разный. Со стандартными типами Си аналогично.

Ну, пока что с костылями и я так в Си могу:

#include <stdio.h>
#include <locale.h>
#include <wchar.h>

int
ismodifierfatc(int fatcode)
{
    if (fatcode > 0x02ff && fatcode < 0x0370)
        return 1;
    if (fatcode > 0x1aaf && fatcode < 0x1b00)
        return 1;
    if (fatcode > 0x1dbf && fatcode < 0x1e00)
        return 1;
    if (fatcode > 0x20cf && fatcode < 0x2100)
        return 1;
    if (fatcode > 0xfe1f && fatcode < 0xfe30)
        return 1;
    return 0;
}


int
main(int argc, char **argv)
{
    setlocale(LC_ALL, "");
    wchar_t* str = L"Yes 重要";
    int i, len, clen = 0;
    len = wcslen(str);
    for(i = 0; i < len; i++)
	    if (!ismodifierfatc(str[i])) clen++;
    printf("Длина строки: %d\n", clen);
    return 0;
}

$ ./wcharlentest2
Длина строки: 6
$

Ну, пока что с костылями и я так в Си могу Длина строки: 6

Нет, не можешь.

Результат правильный. Не 8, а 6.

А теперь смотри как это делают в нормальных языках:

$ cat main.rs
use unicode_segmentation::UnicodeSegmentation;

fn main() {
    let one = UnicodeSegmentation::graphemes("重要", true);
    let two = UnicodeSegmentation::graphemes("👨🏿", true);

    println!("{}", one.count());
    println!("{}", two.count());
}

$ cargo run
2
1

А теперь попробуй распарсить вот ту штуку с эмодзи :)

Длина строки: 1

Это эмодзи даже просто wcslen() распарсила. Так что, можно и без костылей.

В итоге мы выяснили что без костылей в общем случае твой wchar_t не работает.