C обычным fmt::format я для себя сравнивал, там результаты примерно одинаковые с std::format. Спасибо за наводку с FMT_COMPILE - обязательно попробую и дополню - и бенчмарки, и статью, и комментарий. Будет интересно сравнить со своим e_subst, который примерно то же самое умеет делать.
Ничего и не забыли, что вы. Результаты у snprintf, мягко говоря, не блещут, ещё и с буферами возиться. Хотя, для любителей, в своём классе lstring я возможность форматировать строку через snprintf сделал. Естественно, с автоматическим увеличением размера строки при необходимости.
Ну, описываемый мной метод по сути и строит в compile-time древовидную структуру из кусочков строк, и при выполнении схлопывает их в результат. Только здесь эти "кусочки" могут быть не только существующими строками, но и "генераторами", могущими создавать строки на лету. В библиотеке у меня довольно приличное количество разных генераторов, на разные случаи.
Имхо, этот "новый переключатель" работает только пока КПД близкое к нулевому. Когда добьются приемлемого КПД, окажется, что "переключатель" может работать только в одном режиме, а конструкция станет похожа на гидротрансформатор "до степени смешения". И "смешение" здесь от слова "смех".
Там фишка в consexpr. Для каждого типа параметра генерируется только одна ветка
return "....";
Все остальные ветки выкидываются. Создание и возврат std::string будет относительно быстрым, так как до 15 символов помещаются во внутренний буфер строки без аллокации. Возвращать std::string_view было бы быстрее, но он не даёт гарантий null-терминированности, если строку надо будет передавать в C-API. Начиная с C++26 вроде будет std::zstring_view - на null-терминированную строку, это был бы лучший вариант. Ну или использовать мою simstr - там это из коробки :)
А, понял. Вы свои примером реализовали заготовку для питоновского for r in hat:. А цель статьи - показать как внутри C++ реализовывается def magicians_hat(start, end, step):.
Да, теперь точно вижу, что вы не поняли назначение как моего примера. так и вообще, для чего в туториалах даются примеры. У вас, во-первых, получился не базовый класс для построения самих генераторов, а просто класс для получения значений из генераторов. Во-вторых - его многословность и детали, не относящиеся к построению стейт-машин никак не ведёт к цели статьи - объяснению внутреннего механизма работы корутин. В-третьих - раз уж вы решили сделать класс для запуска генераторов "по-современному", то и делайте его правильно - где begin(), end(), где iterator, *iterator, ++iterator? Да уж, концепты в C++98, сильно :) Для чего promise() в корутинах, тоже совершенно не так поняли. Ну и state_ в примере - в стэйт-машинах это не "готов-не готов", а точка перехода внутри функции-генератора, она не может быть ограниченна двумя значениями, в наследниках может быть много точек перехода.
Вы когда ручку игрового автомата дёргаете, выигрыш из ручки выпадает, или из лотка? Я бы мог конечно сделать std::optional<int> pullout_rabbit (), но это совсем не то, как работает механизм корутин в C++. У них как раз ручка resume отдельно, результат отдельно. Именно это и должен показать этот пример, не то, как бы вам хотелось, а то, как оно есть.
Ваши вопросы мне напоминают человека, которому для примера схематичного устройства автомобиля показывают карт, а он спрашивает - "а почему одноместный? Где прикуриватель и дифференциал? Как тут кондиционер может работать, если окон, которые надо закрыть, тут вообще нет? ". Возможно, вам сама концепция "генераторов" совсем не знакома.
Добавлю к предыдущему ответу. В каждом коде есть кнопка "Объяснить код с SourceCraft". Вот что она мне например выдала:
Представленный фрагмент кода на C++ описывает структуру magicians_hat_base, которая служит базовым интерфейсом для работы с «шляпой фокусника». Эта структура предназначена для реализации генератора, который можно возобновлять и проверять на завершённость. Структура содержит: Поле state_ для хранения текущего состояния шляпы. Поле current_rabbit_ для хранения очередного вытащенного «кролика». Конструктор, инициализирующий состояние шляпы. Виртуальный деструктор для корректного уничтожения объектов. Виртуальную функцию pullout_rabbit для возобновления работы генератора. Функцию done для проверки завершённости работы генератора. Функцию destroy для уничтожения объекта. Этот код демонстрирует подход к реализации корутин в C++ до появления корутин в C++20, используя техники, доступные в C++98. Он позволяет создавать генераторы, которые можно приостанавливать и возобновлять, сохраняя состояние между вызовами.
Представленный фрагмент кода на C++ описывает структуру some_hat, которая наследуется от базового класса magicians_hat_base. Эта структура предназначена для реализации генератора, аналогичного корутине в Python, который генерирует последовательность чисел с заданным шагом. В some_hat определены поля класса для хранения начальных параметров генератора (start_, end_, step_) и текущего значения (rabbit_). Конструктор инициализирует эти поля переданными значениями. Виртуальная функция pull_rabbit предназначена для реализации логики генератора, которая будет переопределена в дочернем классе. Этот код демонстрирует подход к реализации корутин в C++ до появления корутин в C++20, используя техники, доступные в C++98. Он позволяет понять, как можно реализовать генератор с сохранением состояния между вызовами, используя классы и виртуальные функции.
Данный фрагмент кода на C++ демонстрирует реализацию генератора, который имитирует поведение корутины. Метод pullout_rabbit использует состояние (state_) для управления выполнением и имитирует ключевое слово yield из Python, позволяя приостановить выполнение и возобновить его с того же места при следующем вызове. В методе используется switch для управления потоком выполнения в зависимости от текущего состояния (state_). В каждом случае (case 1, case 2) происходит установка значения current_rabbit_ и изменение состояния, что позволяет продолжить выполнение с нужного места при следующем вызове метода. Этот подход демонстрирует, как можно реализовать генератор в C++ до появления корутин в C++20, используя состояния и переменные класса для сохранения контекста выполнения между вызовами.
Я ни на что не намекаю, но даже ИИ смог разобраться с этим примером кода.
Да, с базовым примером мною копнуто глубоко, аж до 1998 года, туда не только лишь всё могут. У базовой структуре нет состояний, есть поле, в котором наследники могут хранить любое своё состояние. Базовый класс знает только то, что 0 - завершено. И сколько после этого pullout_rabbit не вызывай , он ничего больше не сделает. Если чуть внимательнее рассмотрите код, сами поймете. Довольно странно ждать от примера для пояснения низкоуровневых механизмов высоких уровней абстракции, наоборот от них стараются избавиться, чтобы показать суть.
С какого-то момента доходы от биржевых спекуляций начинают настолько существенно перекрывать реальные доходы от деятельности, что заниматься собственно реальной деятельностью становится третьестепенной задачей. Важнее хайп, словесные интервенции и рост капитализации.
Во-первых, не позволит, если всё получится все переписать без unsafe, в чём я сильно сомневаюсь. Во-вторых, как и любой другой язык, Rust так же не застрахован от возможных ошибок, пусть меньше, но они будет, не сомневайтесь. В-третьих, а к тридцатому году будет уже готова армия разработчиков, которые будут дальше туда вносить изменения? Или там уже не будет ни кино, ни театров, а один сплошной ИИ?
Ну так я про это и говорю. Переписали код с C++ на Rust. Он не проходит bc. Дальше-то что? Надо или переписать код на С++, чтобы при переделке в Rust он проходил bc, либо дальше переписать код на Rust, чтобы он проходил bc. То есть в любом случае дело не переносе кода, а в поиске ошибок. И где гарантия, что после переделки код хоть и станет проходит bc, но останется эквивалентным по действию старому коду на C++?
C обычным
fmt::formatя для себя сравнивал, там результаты примерно одинаковые сstd::format.Спасибо за наводку с
FMT_COMPILE- обязательно попробую и дополню - и бенчмарки, и статью, и комментарий. Будет интересно сравнить со своимe_subst, который примерно то же самое умеет делать.Ничего и не забыли, что вы.
Результаты у
snprintf, мягко говоря, не блещут, ещё и с буферами возиться.Хотя, для любителей, в своём классе
lstringя возможность форматировать строку черезsnprintfсделал.Естественно, с автоматическим увеличением размера строки при необходимости.
Ну, описываемый мной метод по сути и строит в compile-time древовидную структуру из кусочков строк, и при выполнении схлопывает их в результат. Только здесь эти "кусочки" могут быть не только существующими строками, но и "генераторами", могущими создавать строки на лету. В библиотеке у меня довольно приличное количество разных генераторов, на разные случаи.
Имхо, этот "новый переключатель" работает только пока КПД близкое к нулевому. Когда добьются приемлемого КПД, окажется, что "переключатель" может работать только в одном режиме, а конструкция станет похожа на гидротрансформатор "до степени смешения". И "смешение" здесь от слова "смех".
Тут моя недоработка, постараюсь найти время и дописать к статье небольшое вступление.
Там фишка в consexpr. Для каждого типа параметра генерируется только одна ветка
Все остальные ветки выкидываются. Создание и возврат std::string будет относительно быстрым, так как до 15 символов помещаются во внутренний буфер строки без аллокации.
Возвращать std::string_view было бы быстрее, но он не даёт гарантий null-терминированности, если строку надо будет передавать в C-API. Начиная с C++26 вроде будет std::zstring_view - на null-терминированную строку, это был бы лучший вариант. Ну или использовать мою simstr - там это из коробки :)
В статье про анимированные графики не увидел ни одного анимированного графика, а так хотел. Печально :(
Я вообще-то программирую "в уме". Тут даже электричество не нужно. Или вы процесс набирания слов на клавиатуре считаете программированием?
А, понял. Вы свои примером реализовали заготовку для питоновского
for r in hat:.А цель статьи - показать как внутри C++ реализовывается
def magicians_hat(start, end, step):.Да, теперь точно вижу, что вы не поняли назначение как моего примера. так и вообще, для чего в туториалах даются примеры.
У вас, во-первых, получился не базовый класс для построения самих генераторов, а просто класс для получения значений из генераторов.
Во-вторых - его многословность и детали, не относящиеся к построению стейт-машин никак не ведёт к цели статьи - объяснению внутреннего механизма работы корутин.
В-третьих - раз уж вы решили сделать класс для запуска генераторов "по-современному", то и делайте его правильно - где begin(), end(), где iterator, *iterator, ++iterator?
Да уж, концепты в C++98, сильно :)
Для чего promise() в корутинах, тоже совершенно не так поняли.
Ну и state_ в примере - в стэйт-машинах это не "готов-не готов", а точка перехода внутри функции-генератора, она не может быть ограниченна двумя значениями, в наследниках может быть много точек перехода.
Вы когда ручку игрового автомата дёргаете, выигрыш из ручки выпадает, или из лотка? Я бы мог конечно сделать std::optional<int> pullout_rabbit (), но это совсем не то, как работает механизм корутин в C++. У них как раз ручка resume отдельно, результат отдельно. Именно это и должен показать этот пример, не то, как бы вам хотелось, а то, как оно есть.
Ваши вопросы мне напоминают человека, которому для примера схематичного устройства автомобиля показывают карт, а он спрашивает - "а почему одноместный? Где прикуриватель и дифференциал? Как тут кондиционер может работать, если окон, которые надо закрыть, тут вообще нет? ".
Возможно, вам сама концепция "генераторов" совсем не знакома.
Добавлю к предыдущему ответу. В каждом коде есть кнопка "Объяснить код с SourceCraft". Вот что она мне например выдала:
Я ни на что не намекаю, но даже ИИ смог разобраться с этим примером кода.
Да, с базовым примером мною копнуто глубоко, аж до 1998 года, туда не только лишь всё могут. У базовой структуре нет состояний, есть поле, в котором наследники могут хранить любое своё состояние. Базовый класс знает только то, что 0 - завершено. И сколько после этого pullout_rabbit не вызывай , он ничего больше не сделает. Если чуть внимательнее рассмотрите код, сами поймете. Довольно странно ждать от примера для пояснения низкоуровневых механизмов высоких уровней абстракции, наоборот от них стараются избавиться, чтобы показать суть.
С какого-то момента доходы от биржевых спекуляций начинают настолько существенно перекрывать реальные доходы от деятельности, что заниматься собственно реальной деятельностью становится третьестепенной задачей. Важнее хайп, словесные интервенции и рост капитализации.
К такому надо © ставить.
Так они как раз и собираются переписывать API системы и её ядро, и там это будет не 1-3%.
Она и есть за меня будет?
Во-первых, не позволит, если всё получится все переписать без unsafe, в чём я сильно сомневаюсь. Во-вторых, как и любой другой язык, Rust так же не застрахован от возможных ошибок, пусть меньше, но они будет, не сомневайтесь. В-третьих, а к тридцатому году будет уже готова армия разработчиков, которые будут дальше туда вносить изменения? Или там уже не будет ни кино, ни театров, а один сплошной ИИ?
Ну так я про это и говорю. Переписали код с C++ на Rust. Он не проходит bc. Дальше-то что?
Надо или переписать код на С++, чтобы при переделке в Rust он проходил bc, либо дальше переписать код на Rust, чтобы он проходил bc. То есть в любом случае дело не переносе кода, а в поиске ошибок.
И где гарантия, что после переделки код хоть и станет проходит bc, но останется эквивалентным по действию старому коду на C++?