Слабак! Вот saahriktu не проверяет пользовательский ввод, например, вот это уровень!

Знаю. Но зачем извращаться с этим дебилизмом, когда N'й символ в человеческих кодировках вычисляется как str[N*k], где k == 1 для однобайтных и 4 для хрюникода-32?

Слабак! Вот saahriktu не проверяет пользовательский ввод, например, вот это уровень!

Разве он хоть что-то написал? Oo

На его сайте есть «программы», да.

Знаю. Но зачем извращаться с этим дебилизмом, когда N'й символ в человеческих кодировках вычисляется как str[N*k], где k == 1 для однобайтных и 4 для хрюникода-32?

Не знаю, а зачем вы извращаетесь, работая с текстом на языке, который для этого не предназначен?

Я лучше возьму rust или Go

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

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

и будешь страдать, да.

Вы и доказывайте

Зачем мне доказывать очевидное? Если мне моча в голову стукнет, и я захочу файл обозвать кириллицей, то его длина будет составлять до 255 символов. Слабо? =D

Что значит «не предназначен»? С - универсальный ЯП. В отличие от всяких быдлопхытонов. И на С я пишу все: от прошивок микроконтроллеров до серверных демонов и числодробилок. См. мой гитхаб.

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

Ты не то чтобы авторитетная для меня личность в вопросах программирования, прости.

и будешь страдать, да.

Нет, не буду.

Зачем мне доказывать очевидное? Если мне моча в голову стукнет, и я захочу файл обозвать кириллицей, то его длина будет составлять до 255 символов. Слабо? =D

Опять какие-то восхитительные истории.

Что значит «не предназначен»? С - универсальный ЯП. В отличие от всяких быдлопхытонов. И на С я пишу все: от прошивок микроконтроллеров до серверных демонов и числодробилок. См. мой гитхаб.

В демонах требуется работа с текстом? Жги ещё.

А ты на божественной сишечке накатай простую программу, которая будет из текстового файла выбирать строки с N-го по M-й символ

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

Испугайся:

#include "str.h"
#include "usart.h"
/**
 * @brief cmpstr - the same as strncmp
 * @param s1,s2 - strings to compare
 * @param n - max symbols amount
 * @return 0 if strings equal or 1/-1
 */
int cmpstr(const char *s1, const char *s2, int n){
    int ret = 0;
    do{
        ret = *s1 - *s2;
    }while(*s1++ && *s2++ && --n);
    return ret;
}

/**
 * @brief getchr - analog of strchr
 * @param str - string to search
 * @param symbol - searching symbol
 * @return pointer to symbol found or NULL
 */
char *getchr(const char *str, char symbol){
    do{
        if(*str == symbol) return (char*)str;
    }while(*(++str));
    return NULL;
}

Пугаться чего? Собственных реализаций strncmp?

Это - для STM32.

зачем???? ну и если stm32 то не проще ли заюзать для этого inline asm ?

Пугаться чего? Собственных реализаций strncmp?

коммунизма однобайтных кодировок.

зачем?

Затем, что библиотечная функция вызывает выпадение чипа в хардфолт почему-то. Мне так проще.

не проще ли заюзать для этого inline asm?

Нафига оно нужно, когда на С понятней? Ассемблер нужен лишь, скажем, если я захочу порядок бит в uint32_t перевернуть, это одной ассемблерной инструкцией делается, либо если еще что-то ARM'овское заюзать, для чего в С нет готового.

чувак тебя опять вскрыло! поздравляю.

Алсо «распарсить строчку с командой» это не «работа с текстом». Потому что строчка с командой у тебя в ASCII/UTF-8, и проблем с этим у тебя нет.

Откуда мы знаем, может быть, у него на STM32 полнотекстовый поиск.

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

Переводчик работает с текстом. Писатель работает с текстом. Дата-сайнтист - тоже работает с текстом. Все по-разному. Никого из них особенно не трогает сколько байт в кодировке.

Нужна работа с текстом, лол. Редактирование текста в vscode, vim или ed, на худой конец. В котором могу быть части на разных языках, и над которым нужно совершать нетривиальные задачи. А парсинг фиксирванной ASCII строки с заданным форматом это не «работа с текстом» :)

А программист на С работает с текстом и сколько байт в кодировке его очень даже трогает

Очень читабельно.

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

А программист на С работает с текстом и сколько байт в кодировке его очень даже трогает

Чо, правда? Вот смотри, у нас есть GET/POST запрос. Нам важна ТОЛЬКО та часть, которая использует ASCII (потому что нам плевать на содержимое, мы его рассматриваем как бинарный блоб). И это без учета того, что можно просто взять готовые строковые либы и не насиловать себе мозг.

Если мне моча в голову стукнет

Да она уже. А может чего и посильнее.

для гомосеков

У тебя богатый опыт

А что тогда по-твоему «работа с текстом», если не тупой парсинг и поиск подстрок? Что там может быть еще эдакого?

А что тогда по-твоему «работа с текстом», если не тупой парсинг и поиск подстрок? Что там может быть еще эдакого?

Ну лол же.

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

из текстового файла выбирать строки с N-го по M-й символ

Это не сложно. Я так делал. Стандарт юникода для этого читать не нужно. Достаточно 2й таблички на https://ru.wikipedia.org/wiki/UTF-8

Хотел пошутить про мертвечину

…но сдержался.

И где в этих задачах встаёт практическая проблема в случае, когда число символов не равно числу байт?

В этом случае N'й символ нельзя вычислить как str[N], очевидно же!

из текстового файла выбирать строки с N-го по M-й символ

Как хорошо жить в мире, в котором символ - это что-то целое и неделимое. Жаль в нашем мире нужно думать про графемы и прочие прелести реальной типографии.

Ну, тебе делать нехрен - вот и думай. Я лучше о логике программы думать буду, а не о том, сколько байт символ занимает! Графемы же вообще возникают лишь в готовых печатных pdf'ках, которые парсить не нужно.

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

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

А зачем тут Си, если есть божественный awk?

$ awk '{print substr($0,N,M)}' /path/to/file

а не о том, сколько байт символ занимает

Всё уже сделано за вас.

Графемы же вообще возникают лишь в готовых печатных pdf'ках, которые парсить не нужно.

Шта?! Может вы с лигатурами путаете?

Хрюникоду есть место лишь в pdf и прочей гуйне

То есть везде. Так и запишем.

А исходники, ясен пень, в кои8.

Ну если весь текст ровно на одном языке - то всё ок. Жаль с реальным миром это никак не стыкуется.

А парсинг фиксирванной ASCII строки с заданным форматом это не «работа с текстом» :)

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

Ну если весь текст ровно на одном языке - то всё ок. Жаль с реальным миром это никак не стыкуется.

Мне насрать, что у тебя в «реальном мире», но обычно человек кроме родного и английского редко знает другие языки. А чтобы верстать мультиязычную книжку, не нужен хрюникод: всякие умляуты можно теховскими команднами добавить, ведь пишу же я букву «йо», не имея ее на клавиатуре!

Это-то очевидно.

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

Да уж.. Сравни сортировку в кодировке CP866 или даже хрю-32 с сортировкой в хрю-8! В первом случае символы идут последовательно и сравнивать можно тупым (a-b), во втором же случае нужно сначала получить численные значения a и b!!!

где может быть нужно явно заданное смещение в символах, а не байтах

Например, автоматический пейджер, который аккуратно разбивает текст на строки длиной N символов, чтобы не было разрывов слов.

А что тогда по-твоему «работа с текстом», если не тупой парсинг и поиск подстрок?

Поиск подстрок в UTF-8 ничем не отличается от поиска подстрок в кодировках с фиксированной длиной, алё. Ты просто ищешь вхождения массива байт в массиве байт. Ты можешь даже использовать для этого strstr.

Зачем тебе сортировка при парсинге?

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

Мне насрать, что у тебя в «реальном мире», но обычно человек кроме родного и английского редко знает другие языки. А чтобы верстать мультиязычную книжку, не нужен хрюникод: всякие умляуты можно теховскими команднами добавить, ведь пишу же я букву «йо», не имея ее на клавиатуре!

То есть абзац на французском или латинском (для цитирования, например) ты предлагаешь пердолить теховскими командами? Ох лол.

Это как-то уже ближе к редакторам и прочей «человеческой» работе с текстом.

А вообще отличный такой пейджер, который сломается на конфигурации, отличной от конфигурации разработчика. Почти на уровне планировщика (для напоминаний и прочих дней рождений, а не cron), который не знает о часовых поясах.

Кодировки plaintext - utf8, или utf8, а может еще и utf8. Больше ничего пользователю знать не нужно.

Ты про UTF-8 забыл.

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

Ну так C говно, раз для него нет нормальных библиотек для работы с юникодом.

К слову, веб-версия MS Outlook до сих пор для русского языка по дефолту использует KOI8-R. MS — главный союзник фанатов однобайтового шлака! Так победим!

P.S. saahriktu, вот скажи, чем KOI8-R лучше ISO-8859-5? Последняя — стандарт ISO и вообще труЪ.

О, у мочераторов проснулся синдром вахтера. Обожаю этот момент.

libpcre емнип десятки лет юникодна.