Здравствуйте, kov_serg, Вы писали:

R>>Правило №16. Избегайте макросов

_>На всякий случай: Это лишь рекомендации.

Всё верно, там прямо в книге об этом говорится. Но я бы прислушался, всё-таки — не дураки писали.

_>Если бы комитет не употреблял тяжелые наркотики уже бы добавили нормальные макросы в язык. А пока приходится использовать то что есть.

Прям приходится? Ты досконально изучил возможности С++ и понял, что ничто не заменит макросы?

Здравствуйте, rg45, Вы писали:

R>Прям приходится? Ты досконально изучил возможности С++ и понял, что ничто не заменит макросы?
Да. Пока альтернативы нет. С рефлексией она скорее всего появится, но скорее всего будет неудобно.

Здравствуйте, rg45, Вы писали:

R>Всё верно, там прямо в книге об этом говорится. Но я бы прислушался, всё-таки — не дураки писали.
Эти не дураки рекомендуют, а не заставляют других избивать тех кто не следует этим скрежалям.
Там так и написано:

Никакое количество даже самых хороших (мы на это надеемся) советов не могут заменить голову.

Это уже последователи придумывают культ и начинается веселье.

Здравствуйте, rg45, Вы писали:


R>Жульничаешь? Изюм выковыриваешь? Ну, я помогу тебе сделать этот нелёгкий шаг. Сравни следующие два варианта:

R>С корутинами:

R>#include <generator>
R>#include <ranges>
R>#include <vector>

Ты бы еще исходник после препроцессора показал
Я тоже могу часть кода переложить в другой файл и будет меньше букв.

Здравствуйте, so5team, Вы писали:

S>Ну вот как раз здесь параллельно обсуждается использования сопрограмм для написания серверов, обслуживающих десятки тысяч одновременных подключений и сотни тысяч параллельных активностей внутри.

И кому/где удалось сделать такой код на сопрограммах эффективнее, чем традиционными методами?

S>Делать такое с досточной степень эффективности используя низкоуровневый "рукопашный код"

Зачем там "рукопашный" код? Все то же самое отлично и понятно делается на объектах, хранящих текущее состояние, а попадание в нужную точку кода реализуется банальным switch'ем, который компилируется в переход по таблице адресов.

S>значительно дороже по времени, затрачиваемому на разработку.

Только если разработкой занимаются люди, не понимающие толком, как работает компьютер, и умеющие мыслить только в терминах переменных и операций с ними.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>И кому/где удалось сделать такой код на сопрограммах эффективнее, чем традиционными методами?

Евгений, вы читать не умеете или же специально не читаете то, что вам пишут?

S>>Делать такое с досточной степень эффективности используя низкоуровневый "рукопашный код"

ЕМ>Зачем там "рукопашный" код? Все то же самое отлично и понятно делается на объектах, хранящих текущее состояние, а попадание в нужную точку кода реализуется банальным switch'ем, который компилируется в переход по таблице адресов.

Да-да-да. Тут вот в параллельном обсуждении тов.kov_serg продемонстрировал как именно это будет выглядеть.

Спасибо, не надо. Код из 1980-х лучше бы оставить в 1980-х.

ЕМ>Только если разработкой занимаются люди, не понимающие толком, как работает компьютер, и умеющие мыслить только в терминах переменных и операций с ними.

Вы сами-то программировать умеете? Чем докажите?

Здравствуйте, rg45, Вы писали:

R>В центре дискуссии простота и выразительность кода.

Мне это напоминает известную тенденцию перегружать operator + для реализации действия, хоть чем-нибудь ассоциирующегося с добавлением, чтоб "использовать встроенные возможности языка", "писать в духе C++" и т.п.

Здравствуйте, landerhigh, Вы писали:

L>При количестве состояний более трех, а также при появлении вложенных состояний имеет тенденцию превращаться в лютый кошмар

Только при самом кондовом подходе. При минимально грамотном и аккуратном подходе код выглядит практически так же, как и с сопрограммами, все входы/выходы и состояния наглядно прослеживаются. А от путаницы в состояниях прекрасно спасают банальные assert'ы.

Здравствуйте, so5team, Вы писали:

S>Да-да-да. Тут вот в параллельном обсуждении тов.kov_serg продемонстрировал как именно это будет выглядеть.
S>Спасибо, не надо. Код из 1980-х лучше бы оставить в 1980-х.
Причем тут код из 80-x просили как это будет выглядеть на C я на C и привёл.

Так основная идея такая:
1. Любая асинхронная функция имеет состояние.
2. Должна уметь обрабатывать внешние сигналы. как минимум для инициализаци (sevInit) и для освобождения ресурсов (sevDone)
3. Причем гарантируется если был вызван sevInit то обязательно будет вызван sevDone.
4. Управление асинхронной функции передаётся явно и она возвращает 0, если закончили или 1 если еще работает.
(расширение: 2-обработать запрос, -n если хоче заснуть на n шагов/ед.времени, кодов прерывания может быть больше например 3-chunk_ready, ...)
(так же и события для sevCancel, sevBegin, sevEnd, ... )

Отсюда общий интерфейс любой асинхронной функции:

struct afn_t {
  void *ctx;
  int (*setup)(void* ctx,int sev);
  int (*loop)(void* ctx);
};
enum { sevInit, sevDone };

Остальное фантики. loop-fn.h — это реализация stackless корутин на plainC. Не наравится можно писать как больше нравится. На общий подход не влияет.

Вот и всё описание асинхронных функций. Этого более чем достаточно, а теперь почитайте что надо для C++20.coroutines

Здравствуйте, kov_serg, Вы писали:

R>>#include <generator>
R>>#include <ranges>
R>>#include <vector>

_>Ты бы еще исходник после препроцессора показал
_>Я тоже могу часть кода переложить в другой файл и будет меньше букв.

Ну, это ты уже передёргиваешь.

Во-первых, Я использую стандартную библиотеку. Мне не нужно её поддерживать и мне нет дела сколько букв в тех заголовочных файлах.
Во-вторых, у тебя же не только реализация страшная, но и использование тоже. Посмотри сам.
Ну и в-третьих уже обсудили — это макросы. Для тебя это норма, а для меня неприемлемый зашквар.

Здравствуйте, rg45, Вы писали:

R>Ну, это ты уже передёргиваешь.
Каждый ... как он хочет.

R>Во-первых, Я использую стандартную библиотеку. Мне не нужно её поддерживать и мне нет дела сколько букв в тех заголовочных файлах.
А если её нет?
R>Во-вторых, у тебя же не только реализация страшная, но и использование тоже. Посмотри сам.
Это особенности языка C. Зато имеем огромное преимущество в портируемости. Можно собрать под любой утюг.

R>Ну и в-третьих уже обсудили — это макросы. Для тебя это норма, а для меня неприемлемый зашквар.
Я не заставляю использовать макросы. Можно и без них.

Здравствуйте, kov_serg, Вы писали:

_>Здравствуйте, so5team, Вы писали:

S>>Да-да-да. Тут вот в параллельном обсуждении тов.kov_serg продемонстрировал как именно это будет выглядеть.
S>>Спасибо, не надо. Код из 1980-х лучше бы оставить в 1980-х.
_>Причем тут год из 80-x просили как это будет выглядеть на C я на C и привёл.

Ну так оно и в 1980-х выглядело точно так же. Годы идут, хотелось бы чего-то более удобного.

C++ные короутины, если делать их нормально, требуют глубокого погружения в тему. Но если это погружение уже сделано и есть готовая машинерия для поддержки короутин, то писать эти самые короутины становится гораздо проще и удобнее, чем расставлять LOOP_BEGIN/LOOP_POINT/LOOP_END вручную.

Здравствуйте, kov_serg, Вы писали:


R>>Во-первых, Я использую стандартную библиотеку. Мне не нужно её поддерживать и мне нет дела сколько букв в тех заголовочных файлах.
_>А если её нет?

Что за выдумки? Я этот вариант даже рассматривать не стану. Стандартная библиотека — часть языка. Без неё С++ — не С++.

R>>Во-вторых, у тебя же не только реализация страшная, но и использование тоже. Посмотри сам.
_>Это особенности языка C. Зато имеем огромное преимущество в портируемости. Можно собрать под любой утюг.

Не вижу я никаких преимуществ. Вижу корявый, громозкий код. И не надо мне рассказывать про особенности языка С — я сам кое-какое представление имею.

R>>Ну и в-третьих уже обсудили — это макросы. Для тебя это норма, а для меня неприемлемый зашквар.
_>Я не заставляю использовать макросы. Можно и без них.

Ну я основываюсь на твоём примере, который ты предоставил для сравнения. Напиши без них, посмотрим.

Здравствуйте, so5team, Вы писали:

S>Ну так оно и в 1980-х выглядело точно так же. Годы идут, хотелось бы чего-то более удобного.

S>C++ные короутины, если делать их нормально, требуют глубокого погружения в тему. Но если это погружение уже сделано и есть готовая машинерия для поддержки короутин, то писать эти самые короутины становится гораздо проще и удобнее, чем расставлять LOOP_BEGIN/LOOP_POINT/LOOP_END вручную.
Еще раз повторю что для написания функции loop можно использовать что угодно, в том числе c++20.coroutines или кучу if-ов или switch или КА или ползать по заранее построенному графу исполнения. Это не важно.
ps: Можно подумать что вам не надо раставлять co_yield, co_return, ...

Здравствуйте, Евгений Музыченко, Вы писали:

R>>В центре дискуссии простота и выразительность кода.

ЕМ>Мне это напоминает известную тенденцию перегружать operator + для реализации действия, хоть чем-нибудь ассоциирующегося с добавлением, чтоб "использовать встроенные возможности языка", "писать в духе C++" и т.п.

Слишком сложная аналогия для моего понимания.

Здравствуйте, kov_serg, Вы писали:

S>>Ну так оно и в 1980-х выглядело точно так же. Годы идут, хотелось бы чего-то более удобного.

S>>C++ные короутины, если делать их нормально, требуют глубокого погружения в тему. Но если это погружение уже сделано и есть готовая машинерия для поддержки короутин, то писать эти самые короутины становится гораздо проще и удобнее, чем расставлять LOOP_BEGIN/LOOP_POINT/LOOP_END вручную.
_>Еще раз повторю что для написания функции loop можно использовать что угодно, в том числе c++20.coroutines или кучу if-ов или switch или КА или ползать по заранее построенному графу исполнения. Это не важно.

Не важно. Я вообще на примере вашего кода показываю г.Музыченко во что выльется ручная работа с объектами вместо применения безстековых короутин из C++20.

Кому-то обязательно понравится ваш подход. Думаю, что по мере усложнения C++ таковых будет немало.

_>ps: Можно подумать что вам не надо раставлять co_yield, co_return, ...

Так ведь их назначение будет понятно каждому, кто разобрался C++ными короутинами.
Это их отличает от написанных Васей Пупкиным LOOP_BEGIN/LOOP_END/etc. При всем уважении к Васе Пупкину.

Здравствуйте, rg45, Вы писали:

R>Что за выдумки? Я этот вариант даже рассматривать не стану. Стандартная библиотека — часть языка. Без неё С++ — не С++.
Какого именно C++n+1

R>Не вижу я никаких преимуществ. Вижу корявый, громозкий код. И не надо мне рассказывать про особенности языка С — я сам кое-какое представление имею.
Так тут весь код, всегда монжно сделать более компактно.

R>>>Ну и в-третьих уже обсудили — это макросы. Для тебя это норма, а для меня неприемлемый зашквар.
_>>Я не заставляю использовать макросы. Можно и без них.

R>Ну я основываюсь на твоём примере, который ты предоставил для сравнения. Напиши без них, посмотрим.
Вот без макросов

int fn1_loop(fn1_t *my) {                                                       int st=my->loop; switch(st) {case 0:
    
    my->value="Idle";                                                           {st=1;goto leave;case 1:{}}
    my->value="Started";                                                        {st=2;goto leave;case 2:{}}
    my->value="Processing";                                                     {st=3;goto leave;case 3:{}}
    while (*my->param < 10 + my->machineID) {
        my->value="Waiting";                                                    {st=4;goto leave;case 4:{}}
    }
    my->value="Stopped";
                                                                                {st=-1;case -1:{}}} leave: my->loop=st; return st==-1 ? 0 : 1;
}

Но думаю твой внутренний перфекционист будет недоволен

Здравствуйте, kov_serg, Вы писали:

R>>Что за выдумки? Я этот вариант даже рассматривать не стану. Стандартная библиотека — часть языка. Без неё С++ — не С++.
_>Какого именно C++n+1

Любого.

R>>Не вижу я никаких преимуществ. Вижу корявый, громозкий код. И не надо мне рассказывать про особенности языка С — я сам кое-какое представление имею.
_>Так тут весь код, всегда монжно сделать более компактно.

Ну так чего ты не сделал до сих пор? Сделай так же компактно, как в варианте с корутинами.

R>>>>Ну и в-третьих уже обсудили — это макросы. Для тебя это норма, а для меня неприемлемый зашквар.
_>>>Я не заставляю использовать макросы. Можно и без них.

R>>Ну я основываюсь на твоём примере, который ты предоставил для сравнения. Напиши без них, посмотрим.
_>Вот без макросов
_>

_>int fn1_loop(fn1_t *my) {                                                       int st=my->loop; switch(st) {case 0:
    
    my->>value="Idle";                                                           {st=1;goto leave;case 1:{}}
    my->>value="Started";                                                        {st=2;goto leave;case 2:{}}
    my->>value="Processing";                                                     {st=3;goto leave;case 3:{}}
_>    while (*my->param < 10 + my->machineID) {
        my->>value="Waiting";                                                    {st=4;goto leave;case 4:{}}
_>    }
    my->>value="Stopped";
_>                                                                                {st=-1;case -1:{}}} leave: my->loop=st; return st==-1 ? 0 : 1;
_>}
_>

Не-не. Полный текст программы с сылкой на годболт, пожалуйста.

_>Но думаю твой внутренний перфекционист будет недоволен

Правильно думаешь

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Только при самом кондовом подходе.

Евгений, "кондовый" в Вашем понимании подход закончился в 80-х.
Сейчас практически никогда не бывает так, что кто код написал, тот его всю жизнь и поддерживает.

ЕМ>При минимально грамотном и аккуратном подходе код выглядит практически так же, как и с сопрограммами,

Не выглядит

ЕМ>все входы/выходы и состояния наглядно прослеживаются.

Не просматриваются.

ЕМ>А от путаницы в состояниях прекрасно спасают банальные assert'ы.

Не спасают.

Здравствуйте, rg45, Вы писали:

R>Не-не. Полный текст программы с сылкой на годболт, пожалуйста.
https://godbolt.org/z/Tos6MvbeG

ps: у меня godbolt забанен роскомпозором, только через обходные пути открывается