Имхо, этот "новый переключатель" работает только пока КПД близкое к нулевому. Когда добьются приемлемого КПД, окажется, что "переключатель" может работать только в одном режиме, а конструкция станет похожа на гидротрансформатор "до степени смешения". И "смешение" здесь от слова "смех".
Там фишка в 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++?
Очень странное решение. Чем ведь формально оправдывают переход на Rust? Что он более безопасный и там не будет ошибок. Но тогда получается, при переписывании с C++ - эти ошибки надо обнаружить, чтобы перенести код в Rust. Но если при анализе эти ошибки будет обнаружены - так может просто их из С++ кода убрать, не переписывая на Rust.
В городе обычно "Я очень хорошо знаю своих соседей, поэтому фиг им дам интернета". А так - если два соседа хотят и готовы поделить стоимость инета между собой, то они и без посредников это сделают.
Имхо, этот "новый переключатель" работает только пока КПД близкое к нулевому. Когда добьются приемлемого КПД, окажется, что "переключатель" может работать только в одном режиме, а конструкция станет похожа на гидротрансформатор "до степени смешения". И "смешение" здесь от слова "смех".
Тут моя недоработка, постараюсь найти время и дописать к статье небольшое вступление.
Там фишка в 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++?
Очень странное решение. Чем ведь формально оправдывают переход на Rust? Что он более безопасный и там не будет ошибок. Но тогда получается, при переписывании с C++ - эти ошибки надо обнаружить, чтобы перенести код в Rust. Но если при анализе эти ошибки будет обнаружены - так может просто их из С++ кода убрать, не переписывая на Rust.
В городе обычно "Я очень хорошо знаю своих соседей, поэтому фиг им дам интернета".
А так - если два соседа хотят и готовы поделить стоимость инета между собой, то они и без посредников это сделают.
"Иметь ваш код в нашем банке - большая честь".