Дополню предыдущий ответ. Вот тут результат бенчмарка как раз сравнение std::stringstream, std::format и строк simstr на задаче Сформировать "текст число текст".
Спасибо. Стало более понятно. Как я понял, возможен слой неких разных "агентов", которые умеют работать с входными данными разных видов и передавать их в ИИ в формате, который понимает конкретный ИИ.
Как-то вы странно вопрос ставите. Почему сразу "на замену"? Этот как говорить "шуруповёрт на замену перфоратору, стамеска на замену рубанку". Для каждой задачи лучше подбирать подходящий инструмент. И эта либа - просто ещё один инструмент в ряду многих. И как же он может быть на замену format, если сам format там используется? format просто отличная вещь для своих целей, не надо его заменять. stringstream тоже решает свои задачи, хотя судя по бенчмаркам, не очень быстро.
Ответ в стиле "Если вы заблудились, просто идите домой". Спасибо. Я как раз и спрашивал, как это технически делается? Вот этот вот ваш ИИ, он с нами в одной комнате (локальный какой-то) или это где-то сервис в облаке? Продаж за квартал, допустим, под миллион, лежат в базе 1С. Как мне их дать этому ИИ? Если ИИ локальный, то надо как то их перекачать куда-то в его базу и потом на GPU он на них будет обучаться? А если в облаке? Ему надо дать доступ в БД? Он запрос сам напишет или ему надо текст запроса дать? Или надо в чате просто в CSV-формате вбить? Вы не подумайте, я не ёрничаю, не издеваюсь, я просто для себя понять хочу, как это чудо работает?
Я нейросетками как-то не увлекаюсь и профан, поэтому вопрос - вот в таком промпте "Проведи анализ данных о продажах за последний квартал" - где оно будет брать эти данные, из коих и возникает синекдоха отвечания? Их надо как-то подготовить и "скормить" нейросетке? Как это технически происходит?
Да, примерно так и планировалось, очень хотелось максимально оптимизировать построение строк. Хотя, конечно, не все задачи пока можно им сделать, но я работаю над этим :) В бенчмарках как раз последний бенчмарк Build Full Func Name на такой типичный билдер строк.
Собственно, в статье не увидел особой конкретики, кроме того, что увеличилось время сборки, если пихать 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.
И что вам даст эта информация? Чьё то праздное любопытство мне лень удовлетворять. Если вам что-то надо от этого функционала, говорите прямо. Если есть какая-то конкретная критика - говорите прямо. Если вам это не нужно - тогда просто не пользуйтесь. Если хотите знать, кому это надо - устройте опрос, я не могу за других людей отвечать.
Спросите у авторов проектов, наверное. Я то тут при чём? Если у вас есть претензии к std::towupper, задайте вопрос ответственным за стандарты, что она до сих пор там делает.
Предыдущий комментарий не могу редактировать, поэтому добавлю отдельно более развёрнуто. В проектах, которые устраивает использование std::towupper и соответственно ISO 30112
Да, спасибо. Как раз где-то год назад пытался изучать LLVM, смотрел их исходники. Удивился, что во многом у меня и у них подходы к работе со строками совпадают. Однако у них там вроде как нет системы конкатенации строк через expression templates. А вот в Qt (недавно обнаружил) - есть такая система, только они делают через operator %, считай база та же самая, что и у меня, только у меня на этой базе побольше наворочено всякого.
simstr позволяет без проблем использовать кастомные аллокаторы. Вполне реально привязать какие-нибудь свои, быстрые, и все будет ещё быстрее. Собственно, в бенчмарках очень хорошо видна разница между аллокацией в линуксе (~20ns) и Windows (~70ns). Бенчмарки проводились с использованием дефолтного new.
И выложили её на 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, решил не заморачиваться со своей реализацией.
Для смены регистра символов и сравнения строк без учёта регистра используются встроенные таблицы для первой плоскости юникода (до 0xFFFF). Строки считаются представленными в кодировке UTF-8, UTF-16, UTF-32 соответственно. Однако не делается нормализация строк и не обрабатываются ситуации, когда смена регистра символа приводит к изменению их количества. Если вам нужна строгая работа с юникодом, используйте другие средства, например ICU. Суммарно таблицы занимают примерно 64Кб.
Ну так всё правильно, лучше быть богатым и здоровым, чем бедным и больным. Как видим, у авторов статьи не получилось перестать вызывать setenv после инициализации приложения. В этом они обвинили libc, и видимо пошли искать другой дивный язык и библиотеки, которые работают идеально и без ошибок :) Эх, подвёл таки "безопасный Rust", а ведь так надеялись, что нашли серебряную пулю.
Ну почему же не поможет? Если уж такая сильная нужда будет в библиотеке, которая невозбранно в getenv лазит, что никак не отказаться от неё, то для неё можно уж и расстараться и результат в tls скопировать :) Вот если кто-то напрямую будет environ шерстить, тогда уже да... Поверьте мне, есть масса способов заставить что-то работать так, как тебе нужно. Это я как автор механизма плагинов для Конфигуратора 1С (которых штатно нет) говорю :)
Не зря говорят - "В правильно заданном вопросе уже половина ответа". А тут уже 90%. И для 1С :)
Дополню предыдущий ответ.
Вот тут результат бенчмарка как раз сравнение
std::stringstream,std::formatи строк simstr на задаче Сформировать "текст число текст".Спасибо. Стало более понятно. Как я понял, возможен слой неких разных "агентов", которые умеют работать с входными данными разных видов и передавать их в ИИ в формате, который понимает конкретный ИИ.
Как-то вы странно вопрос ставите. Почему сразу "на замену"? Этот как говорить "шуруповёрт на замену перфоратору, стамеска на замену рубанку". Для каждой задачи лучше подбирать подходящий инструмент.
И эта либа - просто ещё один инструмент в ряду многих. И как же он может быть на замену
format, если сам format там используется? format просто отличная вещь для своих целей, не надо его заменять.stringstreamтоже решает свои задачи, хотя судя по бенчмаркам, не очень быстро.Ответ в стиле "Если вы заблудились, просто идите домой". Спасибо.
Я как раз и спрашивал, как это технически делается? Вот этот вот ваш ИИ, он с нами в одной комнате (локальный какой-то) или это где-то сервис в облаке? Продаж за квартал, допустим, под миллион, лежат в базе 1С. Как мне их дать этому ИИ? Если ИИ локальный, то надо как то их перекачать куда-то в его базу и потом на GPU он на них будет обучаться? А если в облаке? Ему надо дать доступ в БД? Он запрос сам напишет или ему надо текст запроса дать? Или надо в чате просто в CSV-формате вбить?
Вы не подумайте, я не ёрничаю, не издеваюсь, я просто для себя понять хочу, как это чудо работает?
Я частенько к рабочему компу подключаюсь через RDP и бывает там же и в инете брожу. Меня сразу за бота примут?
Я нейросетками как-то не увлекаюсь и профан, поэтому вопрос - вот в таком промпте "Проведи анализ данных о продажах за последний квартал" - где оно будет брать эти данные, из коих и возникает синекдоха отвечания? Их надо как-то подготовить и "скормить" нейросетке? Как это технически происходит?
Да, примерно так и планировалось, очень хотелось максимально оптимизировать построение строк. Хотя, конечно, не все задачи пока можно им сделать, но я работаю над этим :)
В бенчмарках как раз последний бенчмарк Build Full Func Name на такой типичный билдер строк.
Собственно, в статье не увидел особой конкретики, кроме того, что увеличилось время сборки, если пихать 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.
И что вам даст эта информация? Чьё то праздное любопытство мне лень удовлетворять. Если вам что-то надо от этого функционала, говорите прямо. Если есть какая-то конкретная критика - говорите прямо. Если вам это не нужно - тогда просто не пользуйтесь. Если хотите знать, кому это надо - устройте опрос, я не могу за других людей отвечать.
Спросите у авторов проектов, наверное. Я то тут при чём?
Если у вас есть претензии к std::towupper, задайте вопрос ответственным за стандарты, что она до сих пор там делает.
Предыдущий комментарий не могу редактировать, поэтому добавлю отдельно более развёрнуто.
В проектах, которые устраивает использование std::towupper и соответственно ISO 30112
Да, спасибо. Как раз где-то год назад пытался изучать LLVM, смотрел их исходники. Удивился, что во многом у меня и у них подходы к работе со строками совпадают. Однако у них там вроде как нет системы конкатенации строк через expression templates.
А вот в Qt (недавно обнаружил) - есть такая система, только они делают через operator %, считай база та же самая, что и у меня, только у меня на этой базе побольше наворочено всякого.
Очевидно всегда, когда в проекте не используется ICU :)
Так там в самой статье уже есть картинка с велосипедами :)
simstr позволяет без проблем использовать кастомные аллокаторы. Вполне реально привязать какие-нибудь свои, быстрые, и все будет ещё быстрее. Собственно, в бенчмарках очень хорошо видна разница между аллокацией в линуксе (~20ns) и Windows (~70ns).
Бенчмарки проводились с использованием дефолтного new.
Библиотека использовалась для своих внутренних проектов, и собственно раньше не была библиотекой :) Просто файлы копировались в папки разных проектов (каюсь, иногда ленюсь и делаю "как проще"). Потом "проще" вылазит боком - перетаскивать фичи из проекта в проект стало муторно. В какой-то момент решил сделать это отдельной либой, начал выкладывать примерно этой зимой. Пол-года примерно пытался довести код до состояния "не стыдно показать людям". И соответственно, всю историю сосквошил в один коммит - там страшные вещи попадались, зачем людей пугать историей :)
Если так подозрительно - вот мой довольно давний проект, в котором эти строки использовались - https://github.com/orefkov/v8sqlite, как видите, ему больше двух дней. Также можно например увидеть версию примерно 2019 года здесь.
По поводу С++17 - к сожалению, не могу отказаться от концептов.
Стандартный класс
std::string- используется только для конвертации между simstr иstd::string,std::string_view. И дляsimple_strчерез стандартные строки реализованыfind_first_of, решил не заморачиваться со своей реализацией.Для смены регистра символов и сравнения строк без учёта регистра используются встроенные таблицы для первой плоскости юникода (до 0xFFFF). Строки считаются представленными в кодировке UTF-8, UTF-16, UTF-32 соответственно. Однако не делается нормализация строк и не обрабатываются ситуации, когда смена регистра символа приводит к изменению их количества. Если вам нужна строгая работа с юникодом, используйте другие средства, например ICU.
Суммарно таблицы занимают примерно 64Кб.
Ну так всё правильно, лучше быть богатым и здоровым, чем бедным и больным.
Как видим, у авторов статьи не получилось перестать вызывать setenv после инициализации приложения. В этом они обвинили libc, и видимо пошли искать другой дивный язык и библиотеки, которые работают идеально и без ошибок :) Эх, подвёл таки "безопасный Rust", а ведь так надеялись, что нашли серебряную пулю.
Ну почему же не поможет? Если уж такая сильная нужда будет в библиотеке, которая невозбранно в getenv лазит, что никак не отказаться от неё, то для неё можно уж и расстараться и результат в tls скопировать :) Вот если кто-то напрямую будет environ шерстить, тогда уже да...
Поверьте мне, есть масса способов заставить что-то работать так, как тебе нужно. Это я как автор механизма плагинов для Конфигуратора 1С (которых штатно нет) говорю :)