co_await c++20

_DEN_,
я компилю с запуском не по-умолчанию, а чистый std::launch::async, создается 512 тредов, которые отрабатывая указанное время освобождаются и дают работать другим.
если поставить 1 секунду вместо 100 миллисекунд, то все так же работает, просто ждать дольше, для видео это будет долго.
разумеется GCC работает по другому, std::launch::async генерит exception.
в принципе и не удивительно, компилер от MS генерит наиболее стабильный код, в то время как GCC любит напихать гибкости и рантайма сложно контролируемого в процессе работы.

во-во, а еще они тут co_await'ы рисуют, хоть бы сделали рабочим придуманное ими ранее )

В плюсах мне понравилось появление std::thread, std::async, std::shared_ptr, std:unique_ptr и другие рабочие фичи, свободная функция std::move.
Все это должно было быть в плюсах с самого их рождения.

 

Отсюда и вопрос (не только у меня) про нужность таких штук, которые почти полностью состоят из implementation defined поведения.

 

Да не, ващет как раз микрософтовский компиллер отличается и всегда отличался своим вольнодумством

 

gcc vs ms compiler - это старый холивар. в том плане что рантайм всегда чуть по разному бобрил ( + - конечно), например shared_mutex - на том же гцц было несколько версий, так что... чуть что сложнее хэлло ворлда сразу надо быть начеку)

 

в gcc хелловорлд весит сотни килобайт под винду, я думаю это не конкурент ms, а нечто отдельное самобытное.

 

> удаляйте мой ак с форума вместе с месагами

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

 

Эти проблемы уже лет 20 никого не волнуют.

 

Виндовс - плохая операционная система.

 

Minzdrav,

Поставьте линукс, ну что бы вернуться на винь

_DEN_,

На самом деле волнуют, столь толстый рантайм содержит в себе кучи ошибок. Такие апп потенциальные дыры в безопасности.

 

А десятки мегабайт системных DLL, без которых приложение не запустится, не подпадают эту категорию?

 

_DEN_,

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

 

Indy_, товарищ termosintez на дифе нашел все же

 

unc1e,

Что именно нашёл ?

Я кучу времени потратил на поиск ошибок в тени, пришёл к выводу что это просто невозможно. Эти ошибки находят иначе, два лишь варинта. Либо анализ фиксов, разработка уже закрытых ошибок, либо поиск в сети крэшдампов и их разработка. Только вторым путём и находятся ошибки. Ядро слишком стабильное, чтобы листая дизасм найти ошибки. Это никто сделать не может, для этого нужна очень сложная автоматика - солверы. Задача на данный момент не разрешима.

 

Indy_, https://twitter.com/ZTermo/status/923132329140289536

 

unc1e, тебя не смущает тег #bsod?

 

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

 

superakira, именно. Отказываются юзать Boost и STL, изобретают велосипеды на мешанине из плоского C и C++98, а потом то им finally подавай, то вообще C++ говно

 

Очевидно, потому что "стандартный" не устраивает? Поведение кода должно быть предсказуемым. А когда поведение кода спрятано под 10-этажным слоем метакода, любой здравомыслящий разработчик задастся вопросом: в случае возникновения проблемы сколько времени уйдёт на перелопачивание всего этого метакода и поиск источника проблемы? А нужно ли мне это вообще? Меньше магии - меньше проблем, проще код сопровождать.

 

SadKo, вот хорошая статья про изобретение велосипедов на примере Boost.Asio: http://www.crazygaze.com/blog/2016/03/04/boost-asio-thread-safety-and-reinventing-the-wheel/

Цитата отлично подходит для любых собственных велосипедов.

 

SadKo, дада именно поэтому каждый начинает колхозить strlen, memcmp итд.
std::string - что тут например может тебя напрячь?
std::vector|map - ?

Много тут из вас в "метакоде" копались? Думаю, что нет. Единственное могу сказать что помню на вс2013 багу с потоками std::thread, но как бы это не так чтобы часто.

А теперь представьте проект с недокументированым колхозным рантаймом, который тупо не отлажен итд.