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

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

A>>Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

_>Лучше этот пример переписать вот так:
_>

void async Button_Click()
_>{
_>    txt.Text=await DownloadAsync();
_>}
_>

_>для одновременно большей красоты и непонятности (при условии, что мы хотим вообще понимать суть происходящего, а не рассчитывать на таинственную магию .net'a). Т.е. в таком коде надо чётко понимать, что между вычислением правой части (причём не важно в отдельном потоке или нет) и самим приравниванием может быть выполнен (в том же потоке) произвольный объём кода.

Т.е. проблема в недостаточной многословности — должно быть, чтоб с 5 метров глядя на монитор было видно, что у нас тут асинхронщина?

A>>Понятно, что цикл обработки сообщений UI потока. Интересуют детали.
_>В каком смысле детали? ) Показать как подключаются обработчики сообщений в каком-то фреймворке или что? ) Или вытащить из исходников библиотеки код самого цикла? )
Интересовало откуда PostData узнает у какого инстанса формы нужно вызвать OnData. Из глобальной переменной? Или PostData это экземплярный метод той же формы.

A>>И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).
_>Я бы сказал что код на C# является линейным. А компилируется это (и соответственно выполняется) в совсем другие сущности. Вот эта "подделка" мне и не нравится.
А ты, видимо, всегда отрубаешь оптимизацию, когда компилируешь C++. Ведь оптимизатор может камня на камне не оставить от твоего исходного кода.

A>>А у меня есть подозрение, что подавляющее большинство программистов, у которых в графе профессии стоит "C++", пишут код так, что ты это, мягко говоря, не назовешь идеоматичным кодом на C++.)
A>>Т.е. не только boost, но и часто STL не знают, а пишут с стиле "C++ 80х".
A>>И еще подозреваю, что самый тормозной код — это код на C++, написанный "индусами".))
A>>А если взять среднестатистических C++ и C# программистов, то на типичном проекте с типичными ограничениями ресурсов (время, деньги) продукт на C++ будет содержать больше багов и (о ужас!) будет тормозить, по сравнению с написанным на C#.

_>Ну я в общем то со всем эти согласен. Я тут уже не раз говорил, что у C++ и C# есть свои ниши, где они однозначно царят, ну и плюс большое промежуточное поле, в котором можно использовать с пользой оба инструмента. По моему мнению Java/C# отлично подходит для не IT компаний (кстати, надо понимать, что таких большинство), а соответственно C++ хорош для высокотехнологичных IT компаний, которые могут позволить себе нанимать не рядовых программистов.

У меня более правдоподобная версия: С/C++ имеет смысл использовать, если требуется производительность любой ценой (даже если это приведет к удорожанию проекта в 10 раз). На C/C++ можно написать более производительный код, но это не значит, что, выбирая С/С++ у нас код автоматом будет более производительным, т.к. для этого, помимо этого выбора, требуется еще вбухать в 10 раз больше ресурсов.
Большинство проектов выглядят так: вот лежит у тебя в трекере задачка "реализовать такое-то поведение"; первое, на что посмотрят когда ты ее сделаешь, это на сколько это поведение корректно реализовано; второе — на сколько код понятен, поддерживаем и расширяем; а на производительность будут смотреть только если тормоза будут слишком заметны. Ближе к концу проекта, если время останется, пройдуться пару раз профайлером, пофиксят пару косячков и в продакшен.
И это все не зависит от выбора языка (мы все еще про большинство проектов). Думаешь какой-нибудь MS Word по другому разрабатывался? Сомневаюсь.
Какой бы тормозной язык не был выбран, в типичном среднесложном проекте, на нем реализованном, имеется "запас оптимизации", превосходящий портирование на C++. Т.е., не меняя язык реализации, можно соптимизировать в десятки или сотни раз, а портирование даст ускорение только в 2-5 раз. После портирования, конечно, можно приложить сверхусилия и добиться производительности, недостижимой для "тормозного языка". Только ресурсов и времени потребуется астрономическое количество. А если брать C++ изначально, то высок шанс просрать дэдлайны и там уж точно не до восокой производительности будет — лишь бы хоть как, но работало.
Короче, я тоже нелюблю тормозные программы, но делать вывод "это потому, что они написаны на таком-то говноязыке" не стал бы. Можно, разве что, предположить, что порог вхождения в язык сильно ниже, поэтому в проект просочились некомпетентные и/или немотивированные люди и т.п. Но это вопрос в людях, а не в языке как таковом. Если этих же людей заставит писать на С++ будут еще большие тормоза, если вообще что-то работать будет...
А С++ не выбирают далеко не только те, которые его не осилили, как тебе могло показаться.