co_await c++20

Честно слабо понял про-что спор.

Лично я вообще против исключений, а за возвращение кодов ошибок.

Кстати а можно сюда выложить перевод стандарта С++ ?

Всё верно, нужно обязательно делать fsync, что-бы удостоверится, что данные записаны.

Правда к С++ это не имеет отношение, это имеет отношение к POSIX-совместимой файловой системе. Вы можете сами свою ФС сделать, где не нужен-будет sync например.

Да согласен, API к С++ имеют скорее косвенные отношения.

Вот ещё пример, Си и стандартная библиотека Си, это не одно и тоже. Вы можете свои реализации работы с памятью, строками и т.д. написать. Можете даже что-то типо своего ООП сделать.

Есть стандарт языка, а есть уже навороты к нему, но эти навороты не являются самим языком.

 

Где я такое говорил? А ну-ка приведите цитату. Не надо путать finally и finalize! Для большинства объектов finalize в Java вообще не нужен!

finally как ключевое слово есть не только в Java. Почему-то в других языках считают допустимым и не зазорным использование этого слова в отличие от мсье Страуструпа.

При чём тут finalize, алё? Вы хотя бы немного Java подучите для начала, чем говорить ерунду.
В C++ можно обойтись без finally, но при определённых случаях это геморрой. Вы не хотите это принять, хотя это факт.
Также как геморрой - прерывание внешнего цикла из второго и более уровне вложенности. Чтобы вывалиться из цикла, надо использовать goto или какие-нибудь булевские переменные и контролить их.
Но зато можно пользоваться лямбдами - просто шикарно [sarcasm].

 

А что плохова в goto ?

ИМХО, вообще если придерживаться определенного "стиля программирования", то нет ничего зазорного в goto.

Если например почитаете стандарт MISRA-C, там про это написанно, то-что метка должна-быть ниже goto, также можно использовать оператор для обработки ошибок, это делать не стыдно.

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

 

SadKo, на счет выхода из цикла - да возможно с ним былобы проще, но это чуть сахар не более. принципиально не влияет. лямбды - вполне себе хорошо.
Парни - это тупой холивар) кто на чем умеет, то на том и кодит. Вот и все.

 

А какой правильный ответ?

 

У тебя Java головного мозга В C++ не нужен finally

Это в Boost.Fibers сразу все идет из коробки - и корутины, и менеджер потоков, и что там еще надо. А C++ coroutines это только кофункции и все. Остальное самому. Если я все правильно понял. На CppCon был доклад на эту тему, но я сходу вспомнить не смог: https://www.youtube.com/user/CppCon

 

TermoSINteZ,

Я интереса ради глянул в сурках, так и не понял что это:

Код (Text):

1. ConvertThreadToFiber(
2.     LPVOID lpParameter
3.     )
4. {
5.  
6.     PFIBER Fiber;
7.     PTEB Teb;
8.  
9.     Fiber = RtlAllocateHeap( RtlProcessHeap(), MAKE_TAG( TMP_TAG ), sizeof(*Fiber) );
10.     if ( !Fiber ) {
11.         SetLastError(ERROR_NOT_ENOUGH_MEMORY);
12.         return Fiber;
13.         }
14.     Teb = NtCurrentTeb();
15.     Fiber->FiberData = lpParameter;
16.     Fiber->StackBase = Teb->NtTib.StackBase;
17.     Fiber->StackLimit = Teb->NtTib.StackLimit;
18.     Fiber->DeallocationStack = Teb->DeallocationStack;
19.     Fiber->ExceptionList = Teb->NtTib.ExceptionList;
20.     Fiber->Wx86Tib = NULL;
21.     Teb->NtTib.FiberData = Fiber;
22.  
23.  
24.     return Fiber;

Походу оно не работает как в рекламе, наверно поэтому я и не помню как оно работает. Эта функция формирует структруру с параметрами поточного стека в буфере и сохраняет это в виде ссылки в TEB. Зачем это делается не понятно. Можно конечно полистать подробно сурки или вообще взять отладчиком открыть да глянуть как оно работает, но это по мойму всё смысла не имеет. Любая манипуляция стеком приведёт к блокировке апп защитой, ну а на уровне юм манипулировать потоками невозможно. Так что этот механизм сомнительный. Даже кажется забавным что тут на рассмотрение его уделяется время.

Смена стека приводит к триггеру на ОП, это делать нельзя ни в каком виде. Ну конечно если вы не хотите что бы система или авер убивало апп. Могу привести примеры.

 

RtlRemoteCall тоже есть в виде экспорта, но оно не рабочее. Вы удивитесь сколько есть запрещённых апи. Их можно вызвать, но защита прибьёт такой вызов.

Даже в старой 8-ке которая у меня есть множество сервисов, которые проверяют стек. Если в нём аномалия, то процесс просто снимается. В последних версиях системы там вообще дикий огород ловушек на такие события, так как это события инжектов. Впрочем это ваше дело. Оно да, запуститься успешно в одном случае из десяти, это без учёта стороннего ав софта и на старых ос.)

 

Правильно ли я понял, что приведённые в качестве примера Firbers, по сути, есть просто переключение программного контекста внутри потока?

Даже в Delphi и в C# есть. Но нет, мыши плакались, кололись, и продолжали есть кактус RAII.

 

Вы делаете поспешные выводы. Слишком много желчи в вас и, в целом, слишком толсто.

 

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

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

 

Что значит "даже"? C# это Java (или Scala) со вкусом Microsoft, ну а Delphi это вообще язык из прошлого века

Ты действительно считаешь, что лучше в каждом месте кода писать руками finally, чем один раз написать освобождение ресурса в декструкторе? Особенно с учетом того, что в 95% случаев и даже этого делать не нужно, поскольку все уже будет из коробки в библиотеках. Пример необходимости в finally в студию, короче.

superakira, корутины не юзал, только читал и смотрел Гарантию того же треда без использования strand можно получить если вместо 1 io_service + N threads юзать N пар 1 io_service + 1 thread (тоже уже обсуждали). Что касается "1 io_service + N threads", то у меня тут недавно был вопрос, на который я сходу не нашел ответ. Пусть в такой конфигурации мы сделали async_read у сокета. Как правильно сделать shutdown без strand? Shutdown не тредсейфный, а в каком потоке выполнится completion handler - неизвестно до тех пор, пока он не начнет выполняться. Мне кажется что с корутинами ответ будет где-то рядом с ответом на этот вопрос

 

Какая-то дичь. Есть какое-то практическое применение, решаемая проблема? Взять к приперу std::thread, не самая удачная вещь, а вот std::async хорошая штука. Вроде простые решения на первый взгляд. Однако поднимают сложность, инвариатность повышается серьезно. Если в деструкторе нужно стопнуть async, то надо хорошо просчитать скорость стопанья, а в большинстве случаев надо сделать force shutdown. Иначе возникают лаги. В браузерах часто применяются promise на JS ну и вы наверно часто встречали лаги и подвисание контента независимо от мощности системы, где-то в деструкторе просчет и практически все висит как при дедлоке. Так вот о чем я, об абстракции. Лучше вынести на другой уровень вопрос параллельных вычислений и отложенных задач, чем вот тот код писать с co_await. Выглядит это как плохой дизайн. C++ конечно язык BDSM в мире программирнга.

Посмотрел boost примеры с co_await. Как и положено в boost архитектура такая, что сами себе проблемы создают и сами придумывают вырвиглазные решения, а потом придумывает вырвиглазные решения для решений и так в цикле для бесконечности.

 

какую проблему они решают? std::thread и std::async дают многопоточность, std::unique_ptr и std::shared_ptr дают контроль за ресурсами и решают проблему delete'ра при разрушении ресурса в другом so/dll. Существует например friend, который не решает никаких проблем, потому как подобная связанность классов/процедур является Конти продуктивной концепции ООП. Или лямбда выражения, которые полезны при максимум пакетной обработке контейнеров, но гавнокодеры их лепят к месту и не месту вместо нормальных процедур.

Ты хоть понимаешь как эти коротины влияют на инвариантность с позиции ООП? Это попытка портануть promise с Javascript. Который является дико рефлективным, рантаймовым истинным ООП. Там это уместно и удобно, потому как там нет потоков и их представления по определению и там рефлексия и функциональный подход,и вот тут это логично вписывается.

Для нубов отдельно линкану полезную ссылку, чтобы понять откуда ноги растут.
https://learn.javascript.ru/promise
В деревне C++ не все вкурсе, что там в городах честного ООП.

 

Может всё-таки наоборот?

 

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

 

с таким подходом можно кого угодно оправдать, типа в правительстве сидят не идиоты, а закон яровой великое благо, поднятие налогов и новые налоги это хорошо, просто вы типа не разбираетесь, и мин.культуры хорошие фильмы снимает, просто вы не разбираетесь. Ну да не повезло с народом в стране, тупой народ. Переношу - не повезло с кодерами, тупые кодеры, смеют критиковать и изучать вопрос. Типа хлебай щи лаптем и молчи!

 

Зачем нужно нечто, неизвестно как и где выполняющееся, сколько потоков создающее и т.д.?