Igors, это ты? :)

[Авварон]

Все эти игры с синтаксисом/семантикой ничего не меняют, так или иначе все крутится вокруг блочка памяти где сидят счетчики ссылок, а из этого ничего особо не выжать.

Как раз выжать можно что угодно, концептуально есть 2 способа владения - уникальное и шаредное. Есть ещё копия, но это то же уникальное (на стеке ли, через clone() ли).
Если вы придумаете какую-то друную идиому, вперед, я послушаю.
Дерево - это уникальное владение (дерево уникально владеет всеми нодами или нода уникально владеет детьми, ноды ссылаются друг на друга через Observer).
Граф - это уникальное владение (граф владеет нодами, связи между нодами задаются через observer_ptr). Я уж молчу что граф можно тупо на индексах постоить а данные хранить в векторе.

[ViTech]

Как раз выжать можно что угодно, концептуально есть 2 способа владения - уникальное и шаредное. Есть ещё копия, но это то же уникальное (на стеке ли, через clone() ли).
Если вы придумаете какую-то друную идиому, вперед, я послушаю.
Дерево - это уникальное владение (дерево уникально владеет всеми нодами или нода уникально владеет детьми, ноды ссылаются друг на друга через Observer).
Граф - это уникальное владение (граф владеет нодами, связи между нодами задаются через observer_ptr). Я уж молчу что граф можно тупо на индексах постоить а данные хранить в векторе.

Уникальное владение - это хорошо . А кто-нибудь "снаружи" дерева может хранить ссылки на его узлы(через observer_ptr)? Или доступ к узлам есть только внутри дерева?

[Igors]

Как раз выжать можно что угодно, концептуально есть 2 способа владения - уникальное и шаредное. Есть ещё копия, но это то же уникальное (на стеке ли, через clone() ли).
Если вы придумаете какую-то друную идиому, вперед, я послушаю.
Дерево - это уникальное владение (дерево уникально владеет всеми нодами или нода уникально владеет детьми, ноды ссылаются друг на друга через Observer).
Граф - это уникальное владение (граф владеет нодами, связи между нодами задаются через observer_ptr). Я уж молчу что граф можно тупо на индексах постоить а данные хранить в векторе.

А владение здесь ни при чем. Граф сам по себе никак с ним не связан, это скорее "наблюдатель" хранящий информацию о связках/ребрах. Когда эти связки обеспечиваются самой структурой данных - необходимости в графе нет, напр узел дерева "знает" свое чайлдво, а часто и наоборот. Однако в случае напр "просто использования" таких связок нет, и придется их создавать. Про индексы Вы что-то загнули, не понял откуда им взяться.

Еще пример когда без графа, мягко говоря, хреновато: скопировать объекты которые могут ссылаться друг на друга. С конструктора/оператора копирования взять нечего, копия ссылается на тот же объект, а тут нужно не так. 

[Old]

А владение здесь ни при чем.

Да что вы.

Граф сам по себе никак с ним не связан, это скорее "наблюдатель" хранящий информацию о связках/ребрах.

Т.е. объекты между собой никак не связаны и спокойно функционируют, а наблюдатель знает какие то связи, но для функционирования системы они не нужны? Кому нужны такие связи?

[_Bers]

А меня удивляют персонажи которые не догоняют разницу).

трудно найти черную кошку в темной комнате, особенно если её там нет.

В асинхронном однопоточном - эвент луп.

под капотом эвент лупа у вас, вестимо,
сферический ваккуум, ога.

попробуйте самостоятельно, с нуля, разработать механизм,
который позволяет совершать асинхронные действия.
тогда может быть до ваших мозгов допрет,
что задача не реализуема в single-thread.

[_Bers]

Вот говорят, std то, std се, это, мол, "основа основ" которую совершенно необходимо изучать, и чем больше - тем лучше. Ну если так, то и все либы что пользуемся должны быть "на основе std", иначе что это за основа такая? Но моя практика говорит обратное. Вот большие, солидные либы что я много пользовался в этом году

не знаю, кто такие эти "все". вы этот вопрос этим "им" и задайте.
так то никто никому ничего не должен,
коли клятв не приносил, и расписок не давал.

[ViTech]

тогда может быть до ваших мозгов допрет,

Всегда восхищали люди, которые уверены, что у них самый правильный мозг в мире . Заходите сюда почаще и накидывайте побольше, а то скучно тут.

[_Bers]

тогда может быть до ваших мозгов допрет,

Всегда восхищали люди, которые уверены, что у них самый правильный мозг в мире . Заходите сюда почаще и накидывайте побольше, а то скучно тут.

асинхронный дизайн реализуется через многопоточный
по определению понятия самой концепции асинхронного программирования.

асинхронный дизайн придумал не я.
и он никак не зависит от моих мозгов.


вы можете попробовать (хотя бы чисто умозрительно-гипотетически, используя псевдоязык)
реализовать ансинхронный дизайн в условиях отсутствия много-поточности.

у вас ничего не получится.
вы столкнётесь с логическим ограничением.
это - невозможно.
как не возможно поделить на ноль, например.

[ViTech]

асинхронный дизайн реализуется через многопоточный
по определению понятия самой концепции асинхронного программирования.

асинхронный дизайн придумал не я.
и он никак не зависит от моих мозгов.

Уже лучше. Можете указать источники знаний про концепции асинхронного программирования? И что там без многопоточности никак. А то каждый много чего себе понапридумывать может.

[Old]

реализовать ансинхронный дизайн в условиях отсутствия много-поточности.

Глупости какие.
Я так понимаю вы под bare metal без RTOS никогда не писали?

Асинхронность легко достигается в одном потоке исполнения.
В нем вы крутите event loop, где одним из действий проверяете поступление данных, например, из uart.
Пока данных нет - вы обрабатываете другие поступающие события, а как только данные появились - зовете обработчик читающий эти данные.

Так же это работает и на обычных система. Вы крутите event loop в одном потоке, в котором проверяете доступность сетевых данных, например, используя механизмы типа select/epoll. Если данные пришли - вызываем обработчик их читающий, нет обрабатываем другие события системы.

Или вы под асинхронностью понимаете только C++ async?

[ssoft]

асинхронный дизайн придумал не я.
и он никак не зависит от моих мозгов.

Ну с этим то я полностью согласен. И это очень даже хорошо).

вы можете попробовать (хотя бы чисто умозрительно-гипотетически, используя псевдоязык)
реализовать ансинхронный дизайн в условиях отсутствия много-поточности.

Про сопрограммы или прерывания ничего не слышали? Только про эвент луп?

Асинхронный дизайн на одном потоке отличается от асинхронного дизайна на множестве потоков только отсутствием необходимости использовать какую-либо синхронизацию.

Понятия синхронный/асинхронный относится к логике - прямой вызов/отложенный вызов.
Понятия однопоточный/многопоточный относится к технической реализации - без синхронизации/с синхронизацией.

Заходите сюда почаще и накидывайте побольше, а то скучно тут.

Да уж  . Сразу намного веселее становится.

[_Bers]

асинхронный дизайн реализуется через многопоточный
по определению понятия самой концепции асинхронного программирования.

асинхронный дизайн придумал не я.
и он никак не зависит от моих мозгов.

Уже лучше. Можете указать источники знаний про концепции асинхронного программирования? И что там без многопоточности никак. А то каждый много чего себе понапридумывать может.

возьми любой букварь (документацию) по любой библиотеке (функции),
которая работает в асинхронном режиме.
и почитай, что это значит.

[_Bers]

Асинхронность легко достигается в одном потоке исполнения.
В нем вы крутите event loop, где одним из действий проверяете поступление данных, например, из uart.
Пока данных нет - вы обрабатываете другие поступающие события, а как только данные появились - зовете обработчик читающий эти данные.

во-первых,
что бы данные смогли поступить, должна отработать процедура их получения.
что в условиях single-thread уже противоречит идее асинхронного дизайна.

а во-вторых, и самое главное,
крутить вручную в том же потоке свою бизнес логику,
и периодически вручную проверять не созрела ли там какая то задача,
это что угодно, но только не асинхронное программирование.



вы вообще понимаете что такое "асинхронный дизайн" ?

асинхронный дизайн: запуск на выполнение не блокирующей функции.

ваш бизнес-поток не блокируется.
инициировав команду: "старт", он продолжает выполнение своей работы.

Код:

...
wait(callbackDataReady);  // <--- когда задача созреет - вам позвонят.
...
...  // <--- остальное время можете заниматься всем, чем угодно
...

примечательно, что "в остальное время можно заниматься всем, чем угодно",
но при этом не забывать о разделяемых ресурсах.
потому что "позвонить" могут в любой момент.

здравствуйте мутексы, здравствуй, много-поточное нутро.


асинхронный дизайн невозможно реализовать в условиях single-thread.
но вы можете попытаться его проиллюстрировать хотя бы в псевдокоде.

не можете?
увы. это - невозможно.

[Old]

во-первых,
что бы данные смогли поступить, должна отработать процедура их получения.
что в условиях single-thread уже противоречит идее асинхронного дизайна.

Глупости. Данные получаются и хранятся в регистре uart, пока не будут вычитаны процедурой получения.

а во-вторых, и самое главное,
крутить вручную в том же потоке свою бизнес логику,
и периодически вручную проверять не созрела ли там какая то задача,
это что угодно, но только не асинхронное программирование.

Это именно асинхронная программа, которая может выполнять любые другие действия, пока не наступит нужно событие.

вы вообще понимаете что такое "асинхронный дизайн" ?

Я да, а вот вы не очень.

асинхронный дизайн: запуск на выполнение не блокирующей функции.

ваш бизнес-поток не блокируется.
инициировав команду: "старт", он продолжает выполнение своей работы.

А он и не блокируется, этот поток выполнения другие операции, которые готовы к обслуживанию.

асинхронный дизайн невозможно реализовать в условиях single-thread.

Еще раз, легко возможно и я выше расписал как.

но вы можете попытаться его проиллюстрировать хотя бы в псевдокоде.

не можете?
увы. это - невозможно.

Конечно могу, посмотрите любой пример из boost.asio использующий async функции. Ту же демку с таймерами. Он выполняется в одном потоке и это легко проверить в любом отладчике.

[_Bers]

вы можете попробовать (хотя бы чисто умозрительно-гипотетически, используя псевдоязык)
реализовать ансинхронный дизайн в условиях отсутствия много-поточности.

Про сопрограммы или прерывания ничего не слышали? Только про эвент луп?

сопрограммы ортогональны асинхронному программированию.
внезапно.

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

Асинхронный дизайн на одном потоке отличается от асинхронного дизайна на множестве потоков только отсутствием необходимости использовать какую-либо синхронизацию.

"асинхронный дизайн на одном потоке" - это что такое вообще?

покажите приме-иллюстрацию.

и если вдруг выясниться, что вызов ваших функций - блокирующий,
значит ваш "асинхронный дизайн на одном потоке"
не имеет никакого отношения к асинхронному дизайну вообще.

Понятия синхронный/асинхронный относится к логике - прямой вызов/отложенный вызов.

а теперь правильный отве:

нет никакого  "отложенного вызова" в контексте асинхронки.

инициация выполнения процедуры задачи происходит сразу же
по факту вызова связанной с нею функции.

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


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