В Си предложили добавить switch-case для строк

Смешно, конечно, вместо того, чтобы … генетики зачем-то упорно продолжают …

У вас есть отличная возможность перестать смеяться и не только приобщиться к увлекательному миру вычислительной биологии, но и показать им «как надо». Ну а пока вы этого не сделали, они уж как могут, через жопу, на коленке.

Вижу свалку. Кучи разнозненных проектов без структуры, системы.

Один видит одно, другой другое, много афоризмов существует на эту тему. Вот этот результат и создаёт движение, а не идеи «безопасного программирования», «защиты памяти», или какие там сейчас новые концепции на повестке дня.

Это и есть результат отсутствия единой экосистемы развитой. Каждый делает что может, как может. В этом есть свои плюсы и хренова гора минусов. Что то пытались стандартизировать, что то смогли стандартизировать, но криво. Что то сделали даже удачно.

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

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

И когда то сишка такой и была.

А положительные стороны можно найти вообще у чего угодно.

А за «error at line 1:4328793» после отдельного валидатора надо бить канделябром по морде, долго и качественно, пока до недоумка, который такие сообщения об ошибках выводит не дойдёт что так делать не надо.

А почему собственно нет? Вполне норм сообщение об ошибке в каком-нибудь серверном софте. Дальше вытаскиваешь JSON из дампа и уже сам смотришь что не так, если тебе это очень нужно.

Но сишникам насрать на оптимизацию, как я заметил. Поэтому лялекс такой тормозной.

У меня вот ни разу не тормозной. На порядки быстрее какой-нибудь сраной венды и тем более гейос. Тормозной он только у рукожопов.

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

Кстати, io_uring отлично ложится на Rust с async. А вот на сишечке такое писать – глаза кровоточат.

Информация о кодировке у тебя будет после парсинга. До парсинга её не будет.

Вот только что-то парсинг не сильно помогает против кракозябр в mp3 тегах.

Мда. Сделать всё неправильно, а потом придумывать костыли - это такая мода у антисишников, или проявления альтернативного интеллекта?

Что характерно, все эти реализации id3 тегов написаны на Си или C++.

Никаких проблем с вашим кодом я не видел и не комментировал.

А это тогда к чему:

Типичная ошибка человека ... не писавшего на нём серьёзные коды

В фортране есть указатели, начиная с фортран-90, и они именно так и названы. И не надо писать, что они там не нужны, что их никто не пользует, современный компилятор из обязан понимать. Ещё раз повторю, «вобще нет указателей и т.д.» по отношению к Фортран-77 означало, что компилятор там был существенно проще чем современный, а не про модель памяти. Именно указателей под названием «указатели», а не «явно это так не называется».

хотя бы 95% скорости

хотя бы 95% скорости железа, конечно же.

UB — не запрет, это у вас самозапрет.

Серьёзно, что ли? На отсутствие закрывающих кавычек у меня тоже самозапрет?

An unmatched ’ or " character is encountered on a logical source line during tokenization

Реальный пункт из списка UB в стандарте Си. Как мне заставить компилятор жрать непарные кавычки? А то он задрал ошибки кидать.

Вас насильно заставили писать на Си? И продолжают заставлять?

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

1. В Фортране всё, что имеет имя является указателем. Говорить «нужны-не нужны» смысла нет, они уже там начиная с первого концепта 1955 года задолго до стандарта 90.

2. Стандарт 90 ввёл слово POINTER, но этим только запутал ситуацию. То, что это слово появилось ничего не изменило. По сути, это слово там не нужно.

3. Не надо обижаться, если бы вы писали на Фортране, вы бы поняли, почему я написал 1. и 2. А именно, почему в Фортране-IV указатели есть, а слова такого нет, и почему в Фортране 90 слово есть, а указателей это слово но добавляет.

Мне кажется, что вы контекст разговора с кем-то другим перенесли на меня. Я комментировал только одну фразу «в Фортране нет указателей». Всё. Моё утверждение - в Фортране всё именованное есть указатель.

ls -lR /lib /usr/lib и получите достаточное представление о том, что такое результат работы экосистемы Си.

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

Нуу, всякие crate и npm, куда зловредов заливают каждый день, конечно лучше.

спасибо дедам

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

Как мне заставить компилятор жрать непарные кавычки?

Пропатчте компилятор, делов то.

UB в случае с NULL-указателем означает, что проблема несоответствия железа и стандарта отдана на откуп компилятора. Чтобы как-то можно было что-то сделать на железе, у которого нет NULL-указателя, соответствующего стандарту. Так там вобще не должно быть Си, если там нет настоящего NULL-указателя.

Уж лучше бы, чем этот switch для строк, в стандарт внесли, что проверка указателя на NULL требует явной записи:
if ( ptr == ((void*)0) ) , а запись
if ( !ptr ) компилятор не должен считать проверкой на NULL...

Как мне заставить компилятор жрать непарные кавычки?

Пропатчте компилятор, делов то.

Отлично. А какой результат должен ожидаться при этом? Примерно такой же как с NULL?

UB в случае с NULL-указателем означает, что проблема несоответствия железа и стандарта отдана на откуп компилятора.

Где это написано? Кто это сказал? Ты это сам выдумал? В стандарте об этом ни слова. Если мы смотрим на язык Си абсолютно «в лоб», без каких-либо влажных фантазий о том, что же именно имел ввиду автор, то все варианты UB – это отстрел жопы, просто какие-то из них компиляторы научились статически распознавать, для каких-то требуется ubsan, а какие-то выстрелят лет через 10.

Вы вырвали кусок из фразы, фразу из контекста. Если хотите, читайте, «в фортране-77 нет слова POINTER», если вам так понятнее.

ничего не изменило

Не изменило для кого? Для разработчиков компиляторов? И в коде компилятора ничего не изменилось, да?

в Фортране всё именованное есть указатель

PARAMETER — именованное? И, если это указатель, то и любая неименованная константа тоже указатель.

Конечно, сам выдумал. Только вы сначала напишите, что делать с железом, если там нет NULL-указателя, подходящего под требования стандарта.

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

Ничего не делать. Сишечка к реальному железу имеет весьма опосредованное отношение. Как тут уже упоминалось, это достаточно абстрактный и при этом убогий язычок. Если тебе кровь из носа нужно писать именно по нулевому адресу, константы NULL или (void*)0 – это не то, что ты хочешь. В основном, потому что нет гарантий что компилятор тебе не поднасрёт, и если не сегодня так послезавтра.

Ты бы ещё спросил, что делать в сишечке чтобы кэш-памятью поуправлять.

Вы вырвали кусок из фразы, фразу из контекста.

Это правда.

ничего не изменило

Не изменило для кого?

Для программистов этого языка. Вообще, революция 1990 года создала новый язык, который назвали Fortran 90. Сообщество разделилось, значительная часть продолжала писать на 77, новички стали изучать 90, 95. В конце концов Nvidia Fortran убила. Но это другая история. Фортрана больше нет.

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

Вы правы.
Но можно было много более обобщить.

PARAMETER — именованное?

Вот это очень интересный вопрос. Если оператор как в 77, то да. Если атрибут, как в 90, то нет.

От этого потихоньку избавляются

прикольно.
видал таких чуваков - с раздвоенным языком, продырявленными ушами в 16 местах, отчиканными пальцами (возможно и не только).
здравствуй, дивный новый мир!

от чего избавляются понятно, а меняют-то на что? на колбасу?

Да. К сожалению, в областях где я работаю (недра ОС, сети, безопасность и около), дохрена Си.

ужас, если в таких областях работают те, кому строковый switch зашибись.

Нет, как раз стандарт чётко пишет, что он хочет он NULL-указателя. Требутеся, чтобы его значение не совпадало ни с одним указателем на данные/код. Что означает, что нужен какой-то адрес, по которому процессор не может хранить данные/код.

Если по нулевому адресу лежат данные, то NULL равный 0x000000 не соответствует стандарту. Не важно, чей там косяк, железа, компилятора, стандарта. Это именно NULL нужно выбирать таким значением, чтобы он не совпал в допустимым указателем, а не наоборот.

(void*)0 – это не то, что ты хочешь

Да, я хочу нулевой адрес, а (void*)0 может быть чем угодно, хоть 0xffffff. Но нужно на уровне железа решить, что по адресу 0xffffff ничего (кода/данных) быть не может. А NULL приколотили к 0x000000 и перестало отличаться обращение по нулевому (zero) адресу и NULL pointer dereference.

И дальше, если вчитываться в стандарт, то получается, что ((void *)1) — нормальный указатель, а ((void *)0) — NULL-указатель, а для получения указателя на нулевой адрес нужно как-то извращаться, типа:

int *pt, zero=0;
pt=(void *)zero;

нет гарантий что компилятор тебе не поднасрёт, и если не сегодня так послезавтра.

Дак, и если писать без UB, то таких гарантий нет.

Зачем тогда вообще нужен string_view?

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

«Хвост необработанной строки» это &str[длина_обработанной_части_строки]. Внезапно.

Другими словами, использовать для JSON и подобных форматов однопроходные парсеры – достаточно паршивая идея.

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

Вообще-то, геном это, сцуко, программа.

В чем принципиальная разница программа или строка?

В общем смысле строка это просто свободный моноид.

Представление в памяти может иметь любое, может быть массивом символов, может быть SLP straight-line program программой.

В чем принципиальная разница программа или строка?

В наличии чётко определённой структуры.

В общем смысле строка это просто свободный моноид.

Однако рептирование в габуляторах кернирует проламирование вламонных сепулек.

Непарные кавычки - это никакое не UB, а синтаксическая ошибка.

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

Вообще теперь вспоминаю что изначально string view было задумано как декоратор для входных параметров чтобы в одну и ту же функцию можно было слать std::string и (char*) невозбранно.

Вот пояснительная листовка 2012 года https://abseil.io/tips/1

Уж лучше бы, чем этот switch для строк, в стандарт внесли, что проверка указателя на NULL требует явной записи:

Нет, не надо так, это только путаницу создаст. Лучше просто NULL-оптимизации запретить и пусть железо/ОС решают что делать при его разыменовании.

(str+len) выглядит намного лучше. Но почему-то часто, особенно в древнем коде, вижу именно конструкции &ptr[pos].

Вообще теперь вспоминаю что изначально string view было задумано как декоратор для входных параметров чтобы в одну и ту же функцию можно было слать std::string и (char*) невозбранно.

И вот тут и возникает вопрос - а что помешало в std::string просто добавить возможность устанавливать сторонний _M_ptr? Зачем понадобилось делать новый отдельный класс, который теперь придётся постоянно синхронизировать с кодом std;;string, который как бы std::string но не совсем std::string и т.п.?

Это одно и то же. Вопрос вкусовщины и контекста. Если ты используешь вокруг a[i] = f(b[i]), то &a[n] будет в тему. А если вокруг всякие p = a; ... *p++ = f(*b++) то (a+n), разумеется, логичнее.

Могу предположить что управление памятью помешало или что-то подобное.

Не понял что там синхронизировать-то.

Просто надо брать строки покороче которые влезают в машинное слово. Даже 4 буквы это более чем достаточно чтобы описать мнемонически любой свич.

Я везде пишу через сложение. &a[n] это тавтология, примерно то же самое что &*a, хотя и чуть замаскированное. Скобки это такой же оператор разыменования как и звёздочка, разыменовывать и потом опять брать адрес странно.

Создайте опрос, что правильнее, &a[n] или (a+n)? Уверен, что мы все узнаем много нового.

Чтобы создать опрос надо сперва запилить свич со строками. Ведь как иначе разбирать результаты опроса?

Классы в C++ это не просто структуры с набором методов в комплекте, у них есть ещё собственный внутренний смысл. И само существование объекта с неким образом заполненными полями имеет значимость, в случае с std::string (как я понял из этой темы) оно означает что данные по адресу _M_ptr эксклюзивно принадлежат данной структуре, а все остальные в лучшем случае могут временно получать в ним доступ как-то читая этот указатель. Если же ты подставляешь в структуру другой указатель, особенно если он нарушает данное соглашение (например это часть более большого аллоцированного блока, управляемого другим кодом), то ты нарушаешь смысл std::string.

Вобщем-то, такое встречается не только в C++, в Си с помощью спрятанных из хедеров структур иногда делают что-то похожее, но в С++ это по-моему прямо повсеместно.

Классы в C++ это не просто структуры

firkax начал изучать С++ - последние времена настали, истинно говорю вам!!11

Есть возможность указать свою функцию компаратор?

Можно ещё добавить дженерики, чтобы было удобнее юзать умные указатели и отказаться от цепепе насовсем.

Последний раз его заметно трогал в 2021 году. В 2023 и 2025 ещё мелкие правки вносил в свой векторный рисователь, который наполовину на нём написан. Но там не особо похоже на современный С++ код.

И через ..дцать лет реализуют то что уже давно было в фортране.

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

под капотом там jump tables и он получается оптимальнее цепочки if

Если конечно мы не знаем вероятности if(ов). А то я видел код, когда в цикле 10000 раз первый вариант, 10 раз второй и 1 раз третий отрабатывают. Да, jump tables классно, когда вариантов много и надо независимость иметь в скорости от их количества, а все они более-менее равны.

хочу модули С, это былоб топ для меня

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

Компилятор только компилирует и ничего более. Наличие модулей заставит всю концепцию работы переделать.

И где этот Plan 9? :)

Недавно появился проект Principia Softwarica 1, объясняющий теорию на примере Plan 9, с помощью литературного программирования. Проект особенно примечателен своим масштабом и глубиной.

До этого была книжка Introduction to Operating Systems Abstractions Using Plan 9 2.

Судя по всему, будущее Plan 9 в академии и образовании, а оттуда уже влияние на весь остальной мир. Хорошо спроектированное ПО не умирает.

- . . . ты хочешь закончить так, как заканчиваю я? Ты хочешь быть
тем, чем стал я?

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

В обеих случаях это базовые концепции (формата данных или языка), а не какие-то костыли типа структурок с параметрами и указателем на реальную строку.

Я правильно понимаю, что вы не против length-based строк как концепции, а против конкретного паттерна реализации? Когда реальная строка расположена отдельно от её метаданных.