Ваши вопросы мне напоминают человека, которому для примера схематичного устройства автомобиля показывают карт, а он спрашивает - "а почему одноместный? Где прикуриватель и дифференциал? Как тут кондиционер может работать, если окон, которые надо закрыть, тут вообще нет? ". Возможно, вам сама концепция "генераторов" совсем не знакома.
Добавлю к предыдущему ответу. В каждом коде есть кнопка "Объяснить код с 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.
В городе обычно "Я очень хорошо знаю своих соседей, поэтому фиг им дам интернета". А так - если два соседа хотят и готовы поделить стоимость инета между собой, то они и без посредников это сделают.
Самое интересно, navigator.hardwareConcurrency может выдавать разные значения даже просто на разных вкладках. На пустой странице у меня выдает 32, на странице с гуглопочтой - 2. На некоторых вкладках 26, где-то 12.
Какой инсайд? Что за мифы? Все изменения в формах, законах, ставках и т.п. - становятся известны чуть ли не за год. Такого не бывает - выкатили новую форму отчётности "и чтоб прям завтра". Обычно минимум месяца три есть на подготовку. Просто у кого-то есть ресурсы чтобы это отслеживать и гибкая платформа, на которой это быстро реализуется, и есть слоупоки, которым для изменения поля в табличке и константы в формуле надо два месяца согласований и полгода работы "опытных программистов".
Всё таки реализация await_transform не совсем универсальная. Туда может прийти не awaitable объект, а объект, который только отдаёт awaitable объект посредством operator co_await. А ещё могут прийти noncopyable/nonmoveable объекты. Я делал такую реализацию:
template<typename Awaiter>
struct await_wrapper {
Awaiter real_;
... всякие нужные штуки
auto await_ready() {
return real_.await_ready();
}
template<typename Promise>
auto await_suspend(std::coroutine_handle<Promise> h) {
.... разные нужные штуки
return real_.await_suspend(h);
}
decltype(auto) await_resume() {
.... разные нужные штуки
return real_.await_resume();
}
};
.....
// В promise_type
template<typename Awaiter>
auto await_transform(Awaiter&& a) {
if constexpr (requires{a.operator co_await();}) {
using aw_type = decltype(a.operator co_await());
return await_wrapper<aw_type>{a.operator co_await(), другие параметры};
} else {
using aw_type = std::remove_reference_t<Awaiter>;
return await_wrapper<aw_type&>{a, this->data_, другие параметры};
}
}
sqlite хорош как локальная встраиваемая база данных для одного-двух клиентов. Для большего количества начинаются проблемы - писать может только один писатель, блокируется вся база. Если не включен WAL - читатели ещё и блокируют писателя. WAL не включить, если клиенты обращаются по сети с разных хостов. Вообще, в самый момент появления в 1С логов в sqlite я задавался вопросом - зачем, а главное, нахрена? ИМХО, логи должны быть максимально быстрыми на запись, то есть в максимально "сыром" виде, а вот для анализа потом отдельными инструментами в спокойном режиме агрегироваться.
WAL в sqlite может использоваться только если все обращения к базе данных производятся с одного компа. Первое же ограничение на https://www.sqlite.org/wal.html:
All processes using a database must be on the same host computer; WAL does not work over a network filesystem.
Если там кластер серверов, пишущих в один файл sqlite - WAL не включить.
— Вот, изволите видеть, так называемая эвристическая машина, — сказал старичок. — Точный электронно-механический прибор для отвечания на любые вопросы, а именно — на научные и хозяйственные. Как она у меня работает? Не имея достаточных средств и будучи отфутболиваем различными бюрократами, она у меня пока не полностью автоматизирована. Вопросы задаются устным образом, и я их печатаю и ввожу таким образом к ей внутрь, довожу, так сказать, до ейного сведения. Отвечание ейное, опять через неполную автоматизацию, печатаю снова я. В некотором роде посредник, хе-хе! Так что, ежели угодно, прошу. Он встал за машинку и шикарным жестом перекинул тумблер. В недрах машинки загорелась неоновая лампочка.
Я так понимаю, тут последний этап уже автоматизирован. А как вопрос ей внутрь попадает?
Ваши вопросы мне напоминают человека, которому для примера схематичного устройства автомобиля показывают карт, а он спрашивает - "а почему одноместный? Где прикуриватель и дифференциал? Как тут кондиционер может работать, если окон, которые надо закрыть, тут вообще нет? ".
Возможно, вам сама концепция "генераторов" совсем не знакома.
Добавлю к предыдущему ответу. В каждом коде есть кнопка "Объяснить код с SourceCraft". Вот что она мне например выдала:
Я ни на что не намекаю, но даже ИИ смог разобраться с этим примером кода.
Да, с базовым примером мною копнуто глубоко, аж до 1998 года, туда не только лишь всё могут. У базовой структуре нет состояний, есть поле, в котором наследники могут хранить любое своё состояние. Базовый класс знает только то, что 0 - завершено. И сколько после этого pullout_rabbit не вызывай , он ничего больше не сделает. Если чуть внимательнее рассмотрите код, сами поймете. Довольно странно ждать от примера для пояснения низкоуровневых механизмов высоких уровней абстракции, наоборот от них стараются избавиться, чтобы показать суть.
С какого-то момента доходы от биржевых спекуляций начинают настолько существенно перекрывать реальные доходы от деятельности, что заниматься собственно реальной деятельностью становится третьестепенной задачей. Важнее хайп, словесные интервенции и рост капитализации.
К такому надо © ставить.
Так они как раз и собираются переписывать API системы и её ядро, и там это будет не 1-3%.
Она и есть за меня будет?
Во-первых, не позволит, если всё получится все переписать без unsafe, в чём я сильно сомневаюсь. Во-вторых, как и любой другой язык, Rust так же не застрахован от возможных ошибок, пусть меньше, но они будет, не сомневайтесь. В-третьих, а к тридцатому году будет уже готова армия разработчиков, которые будут дальше туда вносить изменения? Или там уже не будет ни кино, ни театров, а один сплошной ИИ?
Ну так я про это и говорю. Переписали код с C++ на Rust. Он не проходит bc. Дальше-то что?
Надо или переписать код на С++, чтобы при переделке в Rust он проходил bc, либо дальше переписать код на Rust, чтобы он проходил bc. То есть в любом случае дело не переносе кода, а в поиске ошибок.
И где гарантия, что после переделки код хоть и станет проходит bc, но останется эквивалентным по действию старому коду на C++?
Очень странное решение. Чем ведь формально оправдывают переход на Rust? Что он более безопасный и там не будет ошибок. Но тогда получается, при переписывании с C++ - эти ошибки надо обнаружить, чтобы перенести код в Rust. Но если при анализе эти ошибки будет обнаружены - так может просто их из С++ кода убрать, не переписывая на Rust.
В городе обычно "Я очень хорошо знаю своих соседей, поэтому фиг им дам интернета".
А так - если два соседа хотят и готовы поделить стоимость инета между собой, то они и без посредников это сделают.
"Иметь ваш код в нашем банке - большая честь".
Самое интересно, navigator.hardwareConcurrency может выдавать разные значения даже просто на разных вкладках. На пустой странице у меня выдает 32, на странице с гуглопочтой - 2. На некоторых вкладках 26, где-то 12.
Какой инсайд? Что за мифы? Все изменения в формах, законах, ставках и т.п. - становятся известны чуть ли не за год. Такого не бывает - выкатили новую форму отчётности "и чтоб прям завтра". Обычно минимум месяца три есть на подготовку. Просто у кого-то есть ресурсы чтобы это отслеживать и гибкая платформа, на которой это быстро реализуется, и есть слоупоки, которым для изменения поля в табличке и константы в формуле надо два месяца согласований и полгода работы "опытных программистов".
Всё таки реализация
await_transformне совсем универсальная. Туда может прийти не awaitable объект, а объект, который только отдаёт awaitable объект посредствомoperator co_await. А ещё могут прийти noncopyable/nonmoveable объекты. Я делал такую реализацию:sqlite хорош как локальная встраиваемая база данных для одного-двух клиентов.
Для большего количества начинаются проблемы - писать может только один писатель, блокируется вся база.
Если не включен WAL - читатели ещё и блокируют писателя. WAL не включить, если клиенты обращаются по сети с разных хостов.
Вообще, в самый момент появления в 1С логов в sqlite я задавался вопросом - зачем, а главное, нахрена?
ИМХО, логи должны быть максимально быстрыми на запись, то есть в максимально "сыром" виде, а вот для анализа потом отдельными инструментами в спокойном режиме агрегироваться.
WAL в sqlite может использоваться только если все обращения к базе данных производятся с одного компа.
Первое же ограничение на https://www.sqlite.org/wal.html:
Если там кластер серверов, пишущих в один файл sqlite - WAL не включить.
Что совой об пень, что пнём об сову.
Точно 46 светодиодов? Я увидел 26 латинских букв и 10 цифр.
UPD: На гитхабе написано 40.
Я так понимаю, тут последний этап уже автоматизирован. А как вопрос ей внутрь попадает?