Долгожданная статья ученика Столярова о том, что rust-говно

ээ, а куда ты денешь промежутки между байтами?
Они что пустые будут?
То есть идут символы
4 4 4 2 2 4 4 байта - как ты определишь шестой символ, не проверяя всей последовательности.

Юникод это таблица на ~150000 символов. Очевидно, каждый символ без проблем влезает в int.

Ты ведь в курсе, что есть модифицирующие символы?

там 100500 страниц

libicu не просто так столько весит

Еще раз, ты путаешь юникод со способами кодирования юникода. Для представления 150000 символов достаточно 18 бит или 3 байта. Информатика 10й класс :)

что я путаю то? кодировка - это способ представления символов как раз, а не что-то другое. я не говорил за сам юникод, а за кодировки. Есть кодировки с переменной длиной символа - вот как там индексацию по строке делать?

вот как там индексацию по строке делать?

парсить от начала, как ещё

или индекс хранить

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

Ну он же говорит типа реализацию на коленке можно сделать поддержки.
Если реально с начала парсить, то это как по мне большие проблемы для реализации.

Я ответил на твой вопрос. Еще раз повторю. Делаешь внутреннее представление в котором каждый символ занимает фиксированный размер. Для вывода на печать и общения с внешним миром пишешь свои функции, которые, возможно, будут преобразовывать в utf-8.

кодировки уже есть. какое внутреннее представление делаешь? надо реализовывать поддержки тех кодировок, которые уже есть.

Есть кодировки с переменной длиной символа - вот как там индексацию по строке делать?

Тебе не надо делать индексацию по кодированной строке. Это странная хотелка. Ты же не жалуешься на то, что перед тем как прочитать .txt.gz его надо распаковать.

за час можно максимум реализацию strlen() запилить для UTF-8, чтоб символы в строке считать

Любое внутреннее представление. Можешь сам его изобрести, можешь использовать utf-32. Кодировки сделаны для общения с внешним миром, как у тебя в программе строка устроена это твое личное дело, она может устроена как угодно, если нужна посимвольная индексация, то используй фиксированный размер. Внезапно, во всех готовых библиотеках сделано именно так. Ты что вообще оспорить пытаешься я понять не могу?

странная хотелка? вырезать из строки подстроку получается странная хотелка, так как для неё нужны индекс начала и конца подстроки.

Еще раз, если тебе нужно работать с символами, то используй символьное представление, utf-8 таковым не является.

ты сказал реализовать поддержку на коленке можно, будет PoC?

Конечно, разбить на символы это тривиальная задача.

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

Ты вообще понимаешь что пишешь? Зачем мне все кодировки поддерживать? Мне хватит utf-8 для общения с внешним миром. Если ты за час это не способен написать, то ты профнепригоден.

за час со всеми тестами, выловленными багами, документацией, опакечиванием?

а я причём? я вообще не работаю и не работал никогда программистом.

где ты в ядре возьмёшь библиотеки?

Там же, где и в юзерспейсе. К ядру можно что угодно прилинковать статически и даже динамически, см. модули в линуксе.

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

будет PoC?

Вот набросал PoC за 15 минут. Я его не тестировал, поэтому могут быть баги, но идея ясна:

https://ideone.com/ByPo7v

юникод из коробки идёт. А ни C, ни C++ этого так и не осилили

Вобще wchar_t в C90 уже был. char16_t и char32_t тоже есть.

Вон у меня ман wcsstr пишет conforming to C99.

Да, wchar_t - это формально не юникод и говорят некоторые компиляторы имеют право урезать его даже до 1 байта, но в линухах он всю жизнь вроде 4 байта, в винде кажется 2, что тоже сойдёт.

Или я не понял, какие фичи нужны для поддержки юникода? Каноническая сортировка и нормализация символов?

char16_t и char32_t тоже есть.

Вот, вот, даже строковые литералы есть с префиксами u и U :) Но вроде кто-то выше жаловался, что оно какое-то неполноценное и недоделанное :)

можешь использовать utf-32

UTF-32 не решает задачу «один (видимый) символ - один инт», как ты хочешь.

Сортировка, нормализация, гарантия того что он влезет в тип данных, даже если стандарт юникода изменится и вырастет в размерах.

Но вроде кто-то выше жаловался, что оно какое-то неполноценное и недоделанное :)

В С++ std::format должен обрабатывать Unicode строки при паддинге, и это потребовало достаточно много кода в реализации…

C очевидно просто игнорирует Unicode, поэтому в этом примере нет пробелов перед символом Санта Клауса: https://gcc.godbolt.org/z/ebca3Esrj

Сортировка, нормализация

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

https://github.com/open-i18n/rust-unic/issues/177 например

На Лоре это постили уже? http://cmustdie.com/

Было

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

Ну да, ну да.

кто такой этот Столяров

Переиздание книг Столярова по программированию
https://www.linux.org.ru/news/doc/16184694/history

нет, просто набросы. Судя по тексту он и Си не особо хорошо знает.

интервью с ним: https://youtu.be/o111yYPqLHU

Отличная статья!

Отличный вброс!

Прям видно, как местным растоманам НИБАМБИТ!!111!

Вот статья того же автора, на аналогичную тему, только про Си: http://cmustdie.com/

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

Ты стандартную библиотеку с buuiltin-функциями не путаешь часом?

а если отключишь - то либо должен свои реализации принести, либо получишь ошибку линковки

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

Опять фанбой пытается обосрать кого-то, не изучив бэкграунд!

Ты стандартную библиотеку с buuiltin-функциями не путаешь часом?

Не путаю. Сходу не приведу пример, но то, что компилятор заменяет ручной цикл копирования байтов на тупо вызов memcpy, видел. Тут, правда, флаг какой-то привели, возможно он поможет от такой оптимизации.

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

А ещё если ты вызываешь в коде printf, то компилятор может его заменить на puts. И это я уже воспроизвёл прям щас на godbolt.org:

#include <stdio.h>

int main() {
    printf("Hello, world\n");
    return 0;
}

.LC0:
  .string "Hello, world"
main:
  push rbp
  mov rbp, rsp
  mov edi, OFFSET FLAT:.LC0
  call puts
  mov eax, 0
  pop rbp
  ret

Причём в C понятия nostd вообще нет, формально должна присутствовать вся амбальная библиотека

Но она может не использоваться -nostdlib

В C, кстати, простой цикл копирования байтов компилятор может заменить на memcpy

И отключается это -fno-builtin

Не работает твой способ.

Вот программка, компилирую на godbolt x86_64 clang 13.0.0 с -fno-builtin -nostdlib. Ниже выхлоп.

#include <stdlib.h>

struct foo_t {
  int x[1024];
};

__thread struct foo_t g_foo;

void bar(struct foo_t* foo) {
  g_foo = *foo;
}

int main() {
  struct foo_t* f = (struct foo_t*)malloc(sizeof(struct foo_t));
  bar(f);
  return 0;
}

bar(foo_t*): # @bar(foo_t*)
  push rbp
  mov rbp, rsp
  sub rsp, 16
  mov qword ptr [rbp - 8], rdi
  mov rsi, qword ptr [rbp - 8]
  mov rax, qword ptr fs:[0]
  lea rdi, [rax + g_foo@TPOFF]
  mov edx, 4096
  call memcpy@PLT
  add rsp, 16
  pop rbp
  ret
main: # @main
  push rbp
  mov rbp, rsp
  sub rsp, 16
  mov dword ptr [rbp - 4], 0
  mov edi, 4096
  call malloc
  mov qword ptr [rbp - 16], rax
  mov rdi, qword ptr [rbp - 16]
  call bar(foo_t*)
  xor eax, eax
  add rsp, 16
  pop rbp
  ret
g_foo:
  .zero 4096

Обрати внимание на call memcpy@PLT

А теперь смени компилятор на нормальный и удивись!

Показная объективность. Достаточно легко можно увидеть, что в статье про раст из каждой строчки сквозит презрение. В то время как в статье про си этого нет. Там есть описание недостатков, но не в формате поливания говном.

тут ссылку на его github кидали, там есть код на си.

Я думаю проблема в том, что для того, чтобы конструктивно критиковать Rust нужно, во-первых, его сначала понять, а во-вторых неслабо напрячься, провести глубокое исследование вопроса и выяснить, как в принципе можно лучше решить все те проблемы, что решает Rust. Так как ничего из этого нет и не предвидится, то другой способ «критики» - просто ругать и поливать грязью, давить на эмоции. Ибо исходная цель - деструкция, а не конструктивная полемика.

-fno-builtin

Не хотеть! Эдак придется свои реализации билтинов писать!

из каждой строчки сквозит презрение.

Просто ты воспринимаешь это как презрение. На самом деле истина лежит где-то там.

Вы полностью правы, истина действительно лежит

где-то там

Истина в том, что ученики Столярова полные профаны.