ээ, а куда ты денешь промежутки между байтами? Они что пустые будут? То есть идут символы 4 4 4 2 2 4 4 байта - как ты определишь шестой символ, не проверяя всей последовательности.
что я путаю то? кодировка - это способ представления символов как раз, а не что-то другое. я не говорил за сам юникод, а за кодировки. Есть кодировки с переменной длиной символа - вот как там индексацию по строке делать?
Я ответил на твой вопрос. Еще раз повторю. Делаешь внутреннее представление в котором каждый символ занимает фиксированный размер. Для вывода на печать и общения с внешним миром пишешь свои функции, которые, возможно, будут преобразовывать в utf-8.
Есть кодировки с переменной длиной символа - вот как там индексацию по строке делать?
Тебе не надо делать индексацию по кодированной строке. Это странная хотелка. Ты же не жалуешься на то, что перед тем как прочитать .txt.gz его надо распаковать.
Любое внутреннее представление. Можешь сам его изобрести, можешь использовать utf-32. Кодировки сделаны для общения с внешним миром, как у тебя в программе строка устроена это твое личное дело, она может устроена как угодно, если нужна посимвольная индексация, то используй фиксированный размер. Внезапно, во всех готовых библиотеках сделано именно так. Ты что вообще оспорить пытаешься я понять не могу?
Ты вообще понимаешь что пишешь? Зачем мне все кодировки поддерживать? Мне хватит utf-8 для общения с внешним миром. Если ты за час это не способен написать, то ты профнепригоден.
юникод из коробки идёт. А ни C, ни C++ этого так и не осилили
Вобще wchar_t в C90 уже был. char16_t и char32_t тоже есть.
Вон у меня ман wcsstr пишет conforming to C99.
Да, wchar_t - это формально не юникод и говорят некоторые компиляторы имеют право урезать его даже до 1 байта, но в линухах он всю жизнь вроде 4 байта, в винде кажется 2, что тоже сойдёт.
Или я не понял, какие фичи нужны для поддержки юникода? Каноническая сортировка и нормализация символов?
Ты стандартную библиотеку с 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
Показная объективность. Достаточно легко можно увидеть, что в статье про раст из каждой строчки сквозит презрение. В то время как в статье про си этого нет. Там есть описание недостатков, но не в формате поливания говном.
Я думаю проблема в том, что для того, чтобы конструктивно критиковать Rust нужно, во-первых, его сначала понять, а во-вторых неслабо напрячься, провести глубокое исследование вопроса и выяснить, как в принципе можно лучше решить все те проблемы, что решает Rust. Так как ничего из этого нет и не предвидится, то другой способ «критики» - просто ругать и поливать грязью, давить на эмоции. Ибо исходная цель - деструкция, а не конструктивная полемика.