Комментарии 37
Так может затем в std::string нет привычных функций replace, tolower и т.д., чтобы не носить с собой то, что не используешь?
Я не хочу, чтобы из-за того, что кому-то надо сравнивать юникод-строки без учета регистра, с программой тащить библиотеку icu со всеми таблицами на 40 мегабайт.
В вашей библиотеке есть таблица для юникода. Насколько она полноценная? Для каких случаев подходит?
Для смены регистра символов и сравнения строк без учёта регистра используются встроенные таблицы для первой плоскости юникода (до 0xFFFF). Строки считаются представленными в кодировке UTF-8, UTF-16, UTF-32 соответственно. Однако не делается нормализация строк и не обрабатываются ситуации, когда смена регистра символа приводит к изменению их количества. Если вам нужна строгая работа с юникодом, используйте другие средства, например ICU.
Суммарно таблицы занимают примерно 64Кб.
В каких случаях нужна нестрогая работа с юникодом?
Очевидно всегда, когда в проекте не используется ICU :)
Предыдущий комментарий не могу редактировать, поэтому добавлю отдельно более развёрнуто.
В проектах, которые устраивает использование std::towupper и соответственно ISO 30112
Ок, какие проекты, в которых есть перевод строк в верхний регистр, устроит использование std::towupper, которая иногда будет неправильно работать?
Спросите у авторов проектов, наверное. Я то тут при чём?
Если у вас есть претензии к std::towupper, задайте вопрос ответственным за стандарты, что она до сих пор там делает.
Ну вы же реализовали алгоритмы перевода строки в разные регистры, вот я и пытаюсь понять для кого. Или это "чтобы было"?
И что вам даст эта информация? Чьё то праздное любопытство мне лень удовлетворять. Если вам что-то надо от этого функционала, говорите прямо. Если есть какая-то конкретная критика - говорите прямо. Если вам это не нужно - тогда просто не пользуйтесь. Если хотите знать, кому это надо - устройте опрос, я не могу за других людей отвечать.
на самом деле Главная Проблема - систематическое использование thread-local allocator. точнее, его отсутствие.
сотни раз разницы в 2008 году: https://ders.by/cpp/mtprog/mtprog.html#3.1.1
5-8 раз сегодня: https://ders.by/cpp/norefs/norefs.html#4.2
ЗЫ я использую text и strsz. закрывает все типичные проблемы: https://ders.by/cpp/deque/code.zip
simstr позволяет без проблем использовать кастомные аллокаторы. Вполне реально привязать какие-нибудь свои, быстрые, и все будет ещё быстрее. Собственно, в бенчмарках очень хорошо видна разница между аллокацией в линуксе (~20ns) и Windows (~70ns).
Бенчмарки проводились с использованием дефолтного new.
Замечательно, Вы дали что выше ссылку на свою библиотеку derslib под Boost Software License. Рекомендую выложить её на гитхаб и дать ссылку в хабр-профиле. Ибо посмотрел статьи на Вашем сайте и здесь - очень сложно найти исходники на которые Вы в них ссылаетесь.
PS В карму и коммент +/+ давайте дружить, делать opensource проекты.
Саму библиотеку я начал потихоньку разрабатывать ещё в 2011-2012 годах
И выложили её на GitHub только 2 дня назад (судя по коммитам репозиторий был создан 07.08.2025)? В эпоху LLM'ок, которые без проблем могут сгенерировать тысячи строк кода это выглядит, по крайней мере, подозрительно. Я ни в чём Вас не обвиняю, но, возможно, если бы Вы эту библиотеку опубликовали гораздо более ранее, то у репозитория было бы больше звёзд.
Однако сейчас минимальная версия стандарта для работы библиотеки: C++20 – используются концепты и <format>.
Вот это кстати, не очень хорошее решение, на мой взгляд. Я сам стараюсь разрабатывать на C++20 (там где это сделать можно), но бывают ситуации, когда необходимо работать именно с C++17 (если не C++11) и таких ситуаций много. Далеко ходить не надо, разработка под устаревшие дистрибутивы Astra Linux 1.7.x (которая иногда требуется) требуют C++17 или "обрезанный" C++20 (где есть множество упущений из-за максимально поддерживаемого компилятора компилятора gcc 8.3.0). Да и существует мнение, что большинство проектов в разработке игр все ещё остаётся на C++11 (максимум используют C++17), а бывает и C++98. А C++ по большей части именно в таких проектах используются.
В контексте C++ даунгрейд версий часто необходимость. Сейчас многие ждут стандарт C++26, в то время как не все компиляторы до сих пор все функции C++20 поддерживают (и тем более C++23).
Для меня в работе со строками всегда большой проблемой была кодировка, а именно: реализация алгоритмов конвертации из разных кодировок. На Linux ОС сейчас это сделать проще благодаря стандартным функциям, а в Windows эту задачу решить сложнее. Особенно если нужно поддерживать Windows 7 - 11 сразу. А с более серьёзными проблемами ещё не встречался, какие-то минимальные утилиты для работы со строками всё равно у каждого C++-программиста должны быть (наверное).
В любом случае пример интересный, будет интересно более детально рассмотреть реализацию API поверх стандартного класса string (как я понял, string тут всё же используется, да и заголовочный файл string.h наблюдал в исходном коде).
Я вам секрет открою, чтобы приложение работало под астрой не обязательно собирать его под астрой.
Я вам секрет открою, чтобы приложение работало под астрой не обязательно собирать его под астрой.
Не может быть! Да ладно? Серьёзно? Хм... я только что загуглил в Интернете и это действительно так. Вот так новость, вот так открытие! Оказывается можно собрать проект под одним Linux-дистрибутивом, а работать он может на другом! Удивительно! (сарказм)
Ну, а если серьёзно - Я об этом прекрасно знаю. Я не просто так написал о конкретной версии компилятора GCC 8.3.0, который доступен в Astra Linux 1.7.x. И версия этого компилятора - максимальная (погуглите, мб что интересного для себя откроете).
У меня есть опыт поддержки приложения на Windows 7, 8, 10, 11 и разных дистрибутивах Linux (Debian, Ubuntu, Astra, Red Hat, разных версий). Если бы я постоянно пересобирал проекты на отдельных ОС или разных дистрибутивах и тестил только эти сборки - выглядело бы это, по крайней мере, нелепо. Механизм препроцессора в C/C++ позволяет сделать код кроссплатформенным (погуглите, мб что интересного для себя откроете).
Смысл тогда был приплетать астру с её древним компилятором?
Да Вы что, совсем не читаете комментарий, под которым оставляете свой комментарий? Я приводил пример, в котором требуется использование C++17 или обрезанного по функциям C++20 в Astra Linux 1.7.x, поскольку там выше компилятора GCC 8.3.0 использовать нельзя (по своему опыту). Собственно эта цитата из моего комментария об этом и говорит:
Далеко ходить не надо, разработка под устаревшие дистрибутивы Astra Linux 1.7.x (которая иногда требуется) требуют C++17 или "обрезанный" C++20 (где есть множество упущений из-за максимально поддерживаемого компилятора компилятора gcc 8.3.0).
И компилятор не древний. Да, он вышел в 2019 году, но считать его из-за этого древним ... нелепо. Также как считать C++17 "устарелым". К стандартам C++ термин "устаревание", на мой взгляд, не применим в принципе. Каждый стандарт этого языка может быть использован на том или ином проекте по требованию.
Так я и говорю, что это плохой пример, потому что искусственное ограничение. С таким же успехом можно было написать RHEL7 с его GCC 4.8, но это же не повод в 2025 году оставаться на C++11 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
Да почему "искусственное ограничение"? Не смотрели новости? Недавно у "Аэрофлота" были проблемы с кибербезопасностью (огромной компании) из-за "устаревшего ПО" (в том числе). Кто-то там даже очень древний Windows использовал и ничего - существуют как организации. Пример простой, обычный, повседневный.
Я работаю над проектом, который действительно поддерживает Astra Linux 1.7.x, потому что многие пользователи этой программы сидят именно на ней (где x может отличаться, но это не принципиально). Это не искусственно созданное ограничение, это необходимость. В этом нет совершенно ничего такого, обычная практика.
Это какие-нибудь веб-приложения проще разрабатывать, там всё зависит не от ОС, а от браузера. Постоянно что-то меняется, проще поставлять обновления и т.п., но когда множество пользователей не переезжают на другие версии ОС и сидят на "устаревшей", то могут быть проблемы с поддержкой. А таких пользователей много. Где-нибудь на предприятиях, где удобно сидеть именно на Astra Linux 1.7.x, а не более новой версии.
С таким же успехом можно было написать RHEL7 с его GCC 4.8, но это же не повод в 2025 году оставаться на C++11 (и ожидать от новых библиотек, что они тоже будут его поддерживать)?
Кто-то и на более старых стандартах пишет. Где-то проблемы с кодовой базой (которая писалась ещё с 90-х), а где-то предпочитают стандарт C++11 не без оснований (например, в контексте скорости, оптимизации и прочих причуд). У всех разные ситуации когда тот или иной стандарт использовать.
Если Вы C++-разработчик, то, видимо, у Вас просто ещё не было такого опыта вынужденной поддержки "старых" ОС или дистрибутивов. Ну, всё можно наработать (по необходимости, разумеется).
Если Вы C++-разработчик, то, видимо, у Вас просто ещё не было такого опыта вынужденной поддержки "старых" ОС или дистрибутивов. Ну, всё можно наработать (по необходимости, разумеется).
Приложение, над которым я работаю, запускается на любом линуксе с glibc >= 2.17 (в т.ч. и Астра 1.7), при этом в нём уже несколько лет активно используется C++20. На всякий случай: это не один бинарник, это несколько сотен библиотек, половина из которых сторонние. Так что я уже навидался разного. И добиться этого не так уж и сложно.
Кто-то и на более старых стандартах пишет. Где-то проблемы с кодовой базой (которая писалась ещё с 90-х), а где-то предпочитают стандарт C++11 не без оснований (например, в контексте скорости, оптимизации и прочих причуд). У всех разные ситуации когда тот или иной стандарт использовать.
Ну Бог им судья. Не вижу причин не использовать новые стандарты. Если не позволяет руководство - это нездоровая ситуация. Если проблемы в коде - это нездоровая ситуация. Если завербовала секта свидетелей более лучших оптимизаций на старых стандартах - это тоже нездоровая ситуация.
при этом в нём уже несколько лет активно используется C++20
Т.е. Вы на проекте под Astra Linux 1.7.x используете компилятор GCC 8.3.0, который использует урезанную версию C++20? Тогда, наверное, Вам хорошо известно, что в этой версии компилятора функции C++20 ограничены. Там целый список того, чего нет (можно погуглить).
На всякий случай: это не один бинарник, это несколько сотен библиотек, половина из которых сторонние. Так что я уже навидался разного. И добиться этого не так уж и сложно.
Ну, если один человек участвует параллельно в разработке "несколько сотен библиотек" - это нездоровая ситуация. Как по мне, лучше последовательно и цельно разрабатывать что-то одно, потом переходить к другому и так далее, чем постоянно поддерживать 100+ различных проектов. Обычно этим страдают фрилансеры, которые реально 100+ проектов в год могут делать, но как правило они не цельные получаются, а проект состоит в основном из готовых наборов библиотек и повсеместного применения высокоуровневого API (для ускорения решения задач).
Не вижу причин не использовать новые стандарты.
Ну, так и многие не видят причин не использовать LLM для кодинга везде где только можно, но кто-то предпочитает самостоятельно писать программный код и думать своей головой. Тоже самое всего о всём новом можно сказать.
Я ещё пока не полноценный эксперт в C++ и опыта у меня недостаточно чтобы судить о каких-то глобальных вещах, касающихся данного языка, но где-то читал мнение профессионального игрового разработчика (эксперта), который писал что-то вроде критики новых стандартов C++ и почему игрострой всё ещё остаётся на старых его стандартах. В общем то моё мнение и основано на том, что я прочитал. Рекомендую к прочтению эту статью. Может быть почерпнёте что-то новое для себя.
Собственно, в статье не увидел особой конкретики, кроме того, что увеличилось время сборки, если пихать auto без раздумывания. И что "мы сидим под Visual Studio, на новом стандарте какие-то мувалки и элиминации через регистры, я не просил". То, что время сборки увеличилось из-за более продвинутой оптимизации и продуктовый код будет работать быстрее - ни слова. Игрострой сидит на C++17 потому что "работает - не трогай", вот почему. Чтобы перейти на C++20 в-первую очередь задаются вопросом "а чтобы что?". Переход однозначно вызовет трату ресурсов - протестировать, починить то, что в С++17 работало, а в C++20 перестало или заработало не так (на их любимом MSVC). Вообще, не понимаю - в игрострое они все говорят, что ничего из std не пользуют, ибо "не перформит", всё у них своё, самописное. Так по идее тогда им какая разница то особо, какой стандарт?
Самое критичное у меня при обновлении было где-то в начале нулевых, когда MSVC привели в соответствии со стандартом и переменные, объявленные в заголовке for, стали видны только в for, и не дальше. Да и потом - сколько не помню проблем при обновлениях - всегда было обычно то, что MSVC что-то начинал делать в соответствии со стандартом, а не так, как хотел.
А по поводу моей либы - так как там используется std::format, то GCC из коробки умеет только с 13ой версии. На ранешних - не заработает без переделок. Попробую заняться этим - либо отключать эти фичи, либо тащить fmt::format.
От концептов и requires тоже в-принципе можно отказаться, но очень многословный код получится, со всеми этими enable_if.
Т.е. Вы на проекте под Astra Linux 1.7.x используете компилятор GCC 8.3.0
Нет конечно. Я с самого начала написал: чтобы приложение работало под астрой не обязательно собирать его под астрой. Приложение собирается GCC 14, в котором есть практически полная поддержка C++20.
Ну, если один человек участвует параллельно в разработке "несколько сотен библиотек" - это нездоровая ситуация.
Я нигде не писал, что занимаюсь разработкой в одиночку. Конечно же это не так.
но где-то читал мнение профессионального игрового разработчика (эксперта), который писал что-то вроде критики новых стандартов C++
У меня тоже много предъяв к некоторым фичам новых стандартов, но их можно просто не использовать. К экспертам в C++ стоит относиться настороженно, потому что они зачастую коммерческой разработкой и не занимаются.
почему игрострой всё ещё остаётся на старых его стандартах
Статью я разумееся читал, но в ней пишут не про то, что геймдев сидит на старых компиляторах, а про то, что в геймдеве очень консервативный подход к использованию фич новых стандартов. Что в принципе логично - core language развивается медленно, STL используется по минимуму.
Т.е. Вы на проекте под Astra Linux 1.7.x используете компилятор GCC 8.3.0, который использует урезанную версию C++20? Тогда, наверное, Вам хорошо известно, что в этой версии компилятора функции C++20 ограничены.
Думаю он просто таскает более новый рантайм от свежего GCC вместе с проектом. Так легко можно добиться двоичной переносимости собранного С++ кода. Я и сам так когда-то делал.
которые без проблем могут сгенерировать тысячи строк кода
Python-кода, может быть, его полно в выборке любой нейросетки. На C++ такого опыта не имел, проблемы были, причем серьезные, и разработка подобного проекта сильно затянется, не говоря уже о точности написания кода. LLM такой код нормально может и объяснит, но не напишет без внешней помощи. У LLM бзик писать среднестатистический код, а среднестатистический код, особенно испорченный кучей логики плохих проектов на Python будет плох и на C++, я бы сказал, особенно на C++. У не понимающего человека явно не получится направить ее в правильную сторону. Понимающий же максимум сможет в качестве помощника использовать, чтобы бойлерплейт какой-нибудь не писать, но не генерировать тысячи строк осмысленного кода без проблем.
У LLM бзик писать среднестатистический код
это не бзик, это by design
LLM такой код нормально может и объяснит, но не напишет без внешней помощи.
Не стоит недооценивать LLM. Они могут очень многое, даже уже сейчас. Любые оценки возможностей LLM так или иначе субъективны. И могут они или чего-то не могут - это временно. Сегодня они "не могут писать сложный код", а завтра - научатся. Сегодня они "не могут выстраивать сложную техническую архитектуру", а завтра - смогут. Сегодня они "всё равно не понимают контекст бизнеса, модели, и т.д.", а завтра - смогут. Всё это временно, рынок уже на хайпе, куча вещей в области AI стремительно разрабатывается, а обратная связь от людей по типу "LLM чего-то не могут" - это просто дополнительный фактор развития LLM'ок, которые в конечном итоге смогут делать вообще всё.
минимальная версия стандарта для работы библиотеки: C++20 – используются концепты и <format>. Вот это кстати, не очень хорошее решение, на мой взгляд.
Глубоко и горячо поддерживаю. Чем ближе к с99 - тем безопаснее для здоровья и умственной гигиены.
И выложили её на GitHub только 2 дня назад (судя по коммитам репозиторий был создан 07.08.2025)? В эпоху LLM'ок, которые без проблем могут сгенерировать тысячи строк кода это выглядит, по крайней мере, подозрительно.
Библиотека использовалась для своих внутренних проектов, и собственно раньше не была библиотекой :) Просто файлы копировались в папки разных проектов (каюсь, иногда ленюсь и делаю "как проще"). Потом "проще" вылазит боком - перетаскивать фичи из проекта в проект стало муторно. В какой-то момент решил сделать это отдельной либой, начал выкладывать примерно этой зимой. Пол-года примерно пытался довести код до состояния "не стыдно показать людям". И соответственно, всю историю сосквошил в один коммит - там страшные вещи попадались, зачем людей пугать историей :)
Если так подозрительно - вот мой довольно давний проект, в котором эти строки использовались - https://github.com/orefkov/v8sqlite, как видите, ему больше двух дней. Также можно например увидеть версию примерно 2019 года здесь.
По поводу С++17 - к сожалению, не могу отказаться от концептов.
Стандартный класс std::string - используется только для конвертации между simstr и std::string, std::string_view. И для simple_str через стандартные строки реализованы find_first_of, решил не заморачиваться со своей реализацией.
Странно, что никто ещё не запостил мем "чтобы избавить пользователей от несовместимости 46 проприетарных разъемов, мы придумали 47й".
В недрах библиотеки LLVM тоже используется ряд своих строковых классов - StringRef, StringView, Twine. Советую обратить внимание на их устройство.
Да, спасибо. Как раз где-то год назад пытался изучать LLVM, смотрел их исходники. Удивился, что во многом у меня и у них подходы к работе со строками совпадают. Однако у них там вроде как нет системы конкатенации строк через expression templates.
А вот в Qt (недавно обнаружил) - есть такая система, только они делают через operator %, считай база та же самая, что и у меня, только у меня на этой базе побольше наворочено всякого.
В карму/статью/либу +/+/+. Вещь хорошая, мнималистичная, в хозяйстве может пригодиться.
Давайте дружить, делать opensource проекты.
simstr — ещё одна строковая библиотека