Здравствуйте, Ikemefula, Вы писали:
EP>>На stackless coroutine такая инкапсуляция не получится — асинхронные кишки будут торчать в клиентском коде, ибо такие сопроцедуры сразу возвращают управление в клиентский код — а это значит что либо данные ещё не получены, либо никакой асинхронности, так как только один поток. I>"ибо такие сопроцедуры сразу возвращают управление в клиентский код" это как, если сопроцедура не сразу возвращает управление в клиентский код, то получается отсутствие асинхрощины ?
Чтобы тебе было понятней, покажи аналог кода на C#:
Здравствуйте, Ikemefula, Вы писали:
I>Угадывать по коду, какую задачу ты хотел решать, я не хочу, потому уже который раз прошу описание человеческим языком. I>Без этого у меня складывается ощущение, что ты чего то не понимаешь похоже. Сначала ты был уверен, что в C# нельзя цикл всунуть в имеющийся код. Щас утверждаешь, что цепочка из двух последовательных ожиданий намного сложнее, чем из одного I>Это конечно лучше, чем спутать лямбды и внешние ресурсы, но примерно так же смешно.
Не в том дело. Просто если ты пишешь не точный аналог кода, а пропускаешь его часть, то как нам тогда сравнивать эти два куска на предмет красоты и лаконичности языка?
I>Вобщем если хочешь получить внятный ответ, дай внятное описание задачи. Например — 5 параллельных асинхронных тасков, каждый таск состоит из двух(трех, десяти) цепочек. Валяй.
C++ вариант реализации await/async (да, кстати, это всего лишь мой вариант придуманный вчера сходу на форуме, а вообще в C++ их может быть ещё сколько угодно других видов) позволяет писать код на порядок (!) лаконичнее и проще чем C#.
только на 5 разных url параллельно и записываем результат в 5 соответствующих textBox. Соответственно аналог на C++ выглядел так: http://www.rsdn.ru/forum/philosophy/5210899
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>>Код который ты привел, пишут именно вчерашние сиплюсники, силу многолетней привычки "зачем думать и так всё быстро". EP>>>>Код показывает к чему приводят минимальные абстракции в java I>>>Ровно к тому же, что и в Boost EP>>Boost это набор библиотек, ты что сказать-то хотел? I>Java это вобщем тоже набор библиотек по большому счету. И stackfull coroutines там есть. И точно такие же приседания со стеком.
Как это всё относится к выделенному?
EP>>Ещё раз, то что где-то быстрый код написан не на C++ не означает, что при написании аналогичного кода на C++ придётся отказываться от абстракций. Логично же I>Смотря что называть абстракциями. Я вот честно не знаю, что ты под этим понимаешь.
Абстра́кция (от лат. abstractio — отвлечение) — отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения.
Простой пример — при сложении двух векторов, не имеет значения сколько и каких компонентов в этих векторах. С такими элементами можно работать как с элементами абелевой группы, пренебрегая несущественными деталями.
Или другой пример, раз уж тут разговор про C, сортировка элементов для которых есть strict weak ordering — в C++ код будет один, для элементов разных типов и последовательностей. В то время как в C, будет либо один код и потеря производительности, либо много неудобного кода. В итоге в C, в большинстве мест отказываются от производительности в пользу платной абстракции.
EP>>Я тебе показал, что из твоей фразы видно, что ты сравниваешь абсолютно разные задачи на разных языках I>Я показываю, что менеджед код запросто может не быть узким местом, даже если требования к перформансу в виде тактов процессора и тд.
Ну так развей свою мысль, в чём была проблема? Я вижу только сравнение двух языков на основе разных задач:
I>>>Выяснил, что дотнет может справляться с вычислениями быстрее, чем нативная либа с отрисовкой результатов.
I>>>По моему мы остановились на том, что ты не понимаешь слово "типичный" и что это означает. EP>>А где я говорил что-то про типичный? I>Вещи которые ты тут сообщал непосредтсвенно связаны с этим понятием.
Здравствуйте, Ikemefula, Вы писали:
I>>>И что ? Чем это лучше I>>>Тем, что на С++ ? EP>>А где я говорил, что это чем-то лучше, круче? Ты спрашивал про аналог I>Договорились — ничем не лучше Не ясно, с чем же ты раньше спорил
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Boost это набор библиотек, ты что сказать-то хотел? I>>Java это вобщем тоже набор библиотек по большому счету. И stackfull coroutines там есть. И точно такие же приседания со стеком.
EP>Как это всё относится к выделенному?
Если ты хочешь узнать, что не так с джавой, сильно вряд ли я тебе помогу, я джавы не знаю. Минимальных абстракций в твоем коде я не видел — там
________________________низкоуровневый________________________код________________________без________________________каких________________________либо________________________абстракций.
Эдак у тебя ассемлерная инструкция станет минимальной абстракцей, дескать, позволяет работать с процессором не задумываясь о сигналах на конкретных пинах.
Максимум что можно назвать абстракцией это имя массива
EP>Ну так развей свою мысль, в чём была проблема? Я вижу только сравнение двух языков на основе разных задач: EP>
I>>>>Выяснил, что дотнет может справляться с вычислениями быстрее, чем нативная либа с отрисовкой результатов.
Здесь нет никакого сравнения, ты контекст потерял. Здесь сказано, что для конкретной задачи(sic!) узкое место это нативная либа которая занимается отрисовкой. Насколько тормозной дотнет, никого, кроме сиплюсников, не интересует. Просто еще один пример до кучи.
Ну и ясно, что тебе тут мерещится "два числа сложить", не волнуйся, я в курсе.
I>>>>По моему мы остановились на том, что ты не понимаешь слово "типичный" и что это означает. EP>>>А где я говорил что-то про типичный? I>>Вещи которые ты тут сообщал непосредтсвенно связаны с этим понятием.
EP>Как именно?
Например
"Почему то самые критичные куски кода пишутся практически на С или подобным образом"
"Я привел пример..."
Чего показал твой один пример ? Что он есть ? Спасибо, это и без тебя ясно было. Или может ты думал, что я утверждаю "никто никогда нигде не писал критичный к перформансу код на с++ и делал бы это успешно" ?
Здравствуйте, vdimas, Вы писали:
IT>>Это не тот ли самый случай из-за чего старый VB тормозил на операциях с памяться раз так в 200? V>Нет, не тот. VB тормозил из-за передачи строк и Safe Array по значению при маршаллинге.
Не скажу за строки, но он жутко тормозил на счётчиках ссылок.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>>>Это твои личные предпочтения. ОК>>Я точно также могу сказать: это твои личные предпочтения!
IT>Вообще-то я ещё никак не выразил своё отношение к var. Я лишь спросил у тебя что плохого в var, но внятного ответа пока так и не услышал.
Ну начинаются эти виляния! Хорошо, поделись своим отношением к вар явно.
Предпочел не услышать.
ОК>>Конкретно там был инт потому что у лонговых литералов в конце суффик "Л."
IT>Да пофиг что там было. Там был счётчик цикла, остальное не важно, в том числе и тип этого счётчика.
Все важно. Если тип слишком маленький, то может возникнуть переполнение, к примеру.
ОК>>На счет шортов не помню но это очень даже хорошо что ты упомянул эти типы поскольку ты, человек, глядя на эту конструкцию не смог сказать истинный тип переменных. Мелочь? Возможно. Но я за то чтобы глядя на переменную сразу видеть ее тип.
IT>Зачем тебе видеть её тип? Вот знаешь ты теперь, что тип этой переменной int и что это тебе даёт? Только объективно, а не "мне хочется знать".
Нету такой вещи как "variable in isolation." Ты работаешь с переменной, тебе нужно знать какие значения она может принимать, ты можешь ее послать в метод или вернуть из метода (а в объявлении метода тебе нужно будет все-таки указать типы!), тебе нужно знать какие методы на ней можно вызвать и наконец ты можешь написать так:
var myVariable = 10;
if (myVariable is long)
DoSomething();
То есть (ошибочно) будешь думать что компилятор выведет один тип а на деле выведет другой.
ОК>>По мне, так это не мусор а получше чем писать вар. Возможное исключение: всякие "вложенные" дженерики. Ну и для линка, конечно же.
IT>Это самый натуральный мусор. Для понимания сути алгоритма типы не важны. Важны возможные действия на данными, например, возможность инкрементирования и использования в качестве индекса в примере с for. Это хорошо подтверждается функциональнами языками, которые по своей выразительности кода внутри метода далеко опережают традиционные языки, в том числе за счёт развитой системы вывода типов.
Что бы ты не говорил, человек все равно мысленно работает как компилятор. Глядя на код, человек держит в уме типы переменных т.к. типы и определяют алгоритм. Что происходит здесь? Медленный линейный поиск по массиву или быстрый look-up в HashSet-e? Даже в случае с счетчиком тебе нужно знать что у типа есть оператор ++. Да и сам счетчик, это уж слишком простое и явное название. Другие имена могут быть не настолько явными. Соседний ответ "подкупил" меня вначале своим спокойствием.
IT>>>Не знаю. Какие? ОК>>Да они только для локальных переменных. Например их нельзя использовать в качестве параметров и return type-а у методов и нельзя использовать в качестве членов класса. Если первое объяснимо, то я не могу предположить ничего на счет второго. По крайней мере на ум ничего не приходит в данный момент. То есть получаются какие-то "кастраты."
IT>Вывод типов прекрасно работает на уровне параметров и возаращаемых значений. Вот пример:
IT>
IT>...Select(x => x.ToString())
IT>
IT>тип параметра x и тип возвращаемого значения выводятся автоматически.
Я не уверен что ты понял меня. Ты вырезал часть диалога. Речь шла об ограничениях контекстно-ключевого слова вар.
ОК>>Я не говорил "придумали." Я сказал "ввели в язык" но да, это все для линка было сделанно было в конечном итоге. Как побочный результат, можно использовать вар для "вложенных дженериков" но уж точно не считаю что вар стоит использовать для интов или простых классов как в твоем примере.
IT>Ещё раз. var может быть и сделан для Linq, но по сути это реализация простенького вывода типов, известного уже давным давно в функциональных языках. Только в ФП вывод типов гораздо мощней. В них типы могут выводится из использования, а var — это вывод типов из инициализации. Если тебе хочется понять преимущества и недостатки вывода типов, то тебе нужно его рассматривать не в узких рамках "for (var i=...", а попытаться осознать всю концепцию и уже потом делать выводы.
Ну вывод типов и вывод типов! Что, только потому что "вар это вывод типов" его следует пихать направо и налево? Несколько странный аргумент. Ты еще начни закатывать глаза и простирать руки к небу: "о, вывод типов!" Напомню что речь шла о том что если можешь объявить тип явно, объяви его. Ну и соответственно мисюз или абьюз этого контекстно-ключевого слова.
IT>>>С тебя всё ещё один — что объективно плохого в var? ОК>>Объясняю это на протяжении нескольких постов.
IT>Пока я не видел ни одного объяснения.
Отказался увидеть.
ОК>>Плохого в них ничего нет но их не создавали чтобы девелоперы использовали их налево и направо. Теперь ты объясни мне что в них хорошего (кроме анонимных типов и вложенных дженериков). Я пока что не услышал ответа.
IT>Кури вывод типов как концепцию. А ещё лучше возьми, например, Немерле и поработай на нём хотя бы пару месяцев. Такие вопросы по for как ты задаёшь отпадут сами собой.
Не считай других глупее себя! Ты вбил себе в голову две вещи. Первая. Вывод типов это круто и поэтому надо везде его использовать. Вторая. Ты решил что я не знаю что такое вывод типов и что такое вар в Шарпе и соответственно приплел в разговор хотя речь была совсем не о выводе типов а о том где и как использовать контекстно-ключевое слово вар. То что это вывод типов к изначальному "вопросу" никакого отношения не имеет. И да, кроме этого твоего вывода типов, я так и не услышал чем же хороши вар в контексте объявления того же счетчика (вместо явного написания инта).
Вопросов по поводу вара у меня нет. Перефразируя тот "вопрос," я скажу что вар в тех двух объявлениях нифига не нужны.
ОК>>Ну и немного не по теме. var — contextual keyword. Могли бы уж и зарезервировать его полностью. А то коряво как-то. Ровно также как и с value в пропертях.
IT>Это к Хейльсбергу.
Так можно сразу отсылать к этому чуваку по любому вопросу. Это я тебе сказал про корявость этих двух фич. Надеюсь ты не отрицаешь этого?
Здравствуйте, alex_public, Вы писали:
_>Не в том дело. Просто если ты пишешь не точный аналог кода, а пропускаешь его часть, то как нам тогда сравнивать эти два куска на предмет красоты и лаконичности языка?
Смотри, ответ прямо сразу был, выделено:
I>>Вобщем если хочешь получить внятный ответ, дай внятное описание задачи. Например — 5 параллельных асинхронных тасков, каждый таск состоит из двух(трех, десяти) цепочек. Валяй.
C++ вариант реализации await/async (да, кстати, это всего лишь мой вариант придуманный вчера сходу на форуме, а вообще в C++ их может быть ещё сколько угодно других видов) позволяет писать код на порядок (!) лаконичнее и проще чем C#.
Ты путаешь язык и либу. В либе можно навернуть все что угодно. Вот смотри, упаковать можно примерно так
И это всего лишь либа. Тебя же все тянет сравнивать языковые возможности с конкретной либой. И что это покажет ? Эдак одна либа на ассемблере может зарулить весь Хаскель с плюсами и даталогом в минуса.
_>Но если всё же почему-то ещё интересно, то та задачка звучала так: делаем в точности тоже самое что и здесь http://www.rsdn.ru/forum/philosophy/5208679
только на 5 разных url параллельно и записываем результат в 5 соответствующих textBox. Соответственно аналог на C++ выглядел так: http://www.rsdn.ru/forum/philosophy/5210899
еще раз у тебя 5 паралельных тасков, каждый из которых асинхронный, из двух цепочек. Сколько цепочек, вообще не важно. Одна, две три — нет разницы. Это понятно ?
Я показал тебе другой фокус — как ожидать таски, которые ты запускаешь. В твоем коде этого нет.
I>>"ибо такие сопроцедуры сразу возвращают управление в клиентский код" это как, если сопроцедура не сразу возвращает управление в клиентский код, то получается отсутствие асинхрощины ?
EP>Чтобы тебе было понятней, покажи аналог кода на C#:
Ты уже в который раз отвечаешь вопросом на вопрос.
EP>getline выполняется асинхронно, давай возможность другим соединениям отработать (поток один). EP>Этот код абсолютно ничем не отличается от синхронного.
когда получит управление код после getline ? Ну, например, если сделать вот так
getline(client_stream, msg);
SendMessage(hwnd,WM_SET_TEXT,msg, NULL); // когда сюда придет управление
Покажи мне эту самую асинхронщину. Для начала выясним, какую часть своего решения ты не показал
Здравствуйте, Олег К., Вы писали:
IT>>Вообще-то я ещё никак не выразил своё отношение к var. Я лишь спросил у тебя что плохого в var, но внятного ответа пока так и не услышал. ОК>Ну начинаются эти виляния! Хорошо, поделись своим отношением к вар явно.
Зачем? Я не пытаюсь никого не убедить, не разубедить, что var это хорошо или плохо. Этим тут ты у нас занимаешься. Вот и объясни, почему ты так считаешь. Пока же ты плавно скатываешь в демагогию.
IT>>Да пофиг что там было. Там был счётчик цикла, остальное не важно, в том числе и тип этого счётчика. ОК>Все важно. Если тип слишком маленький, то может возникнуть переполнение, к примеру.
Если тип слишком маленький, то ты получишь предупреждение от компилятора или решарпера.
IT>>Зачем тебе видеть её тип? Вот знаешь ты теперь, что тип этой переменной int и что это тебе даёт? Только объективно, а не "мне хочется знать".
ОК>Нету такой вещи как "variable in isolation." Ты работаешь с переменной, тебе нужно знать какие значения она может принимать, ты можешь ее послать в метод или вернуть из метода (а в объявлении метода тебе нужно будет все-таки указать типы!), тебе нужно знать какие методы на ней можно вызвать и наконец ты можешь написать так:
ОК>То есть (ошибочно) будешь думать что компилятор выведет один тип а на деле выведет другой.
Здесь ты получишь предупреждение.
IT>>Это самый натуральный мусор. Для понимания сути алгоритма типы не важны. Важны возможные действия на данными, например, возможность инкрементирования и использования в качестве индекса в примере с for. Это хорошо подтверждается функциональнами языками, которые по своей выразительности кода внутри метода далеко опережают традиционные языки, в том числе за счёт развитой системы вывода типов.
ОК>Что бы ты не говорил, человек все равно мысленно работает как компилятор.
Это заблуждение.
ОК>Глядя на код, человек держит в уме типы переменных т.к. типы и определяют алгоритм. Что происходит здесь? Медленный линейный поиск по массиву или быстрый look-up в HashSet-e?
И зачем мне здесь типы? Большинство подобных алгоритмов вообще generics.
IT>>тип параметра x и тип возвращаемого значения выводятся автоматически. ОК>Я не уверен что ты понял меня. Ты вырезал часть диалога. Речь шла об ограничениях контекстно-ключевого слова вар.
Если ты имел ввиду что-то другое, то либо ты невнятно сформулировал, либо у тебя каша в голове
ОК>Ну вывод типов и вывод типов! Что, только потому что "вар это вывод типов" его следует пихать направо и налево? Несколько странный аргумент. Ты еще начни закатывать глаза и простирать руки к небу: "о, вывод типов!"
Похоже ты скатываешься не только в демагогия, но и в хамство. Не советую.
ОК>Напомню что речь шла о том что если можешь объявить тип явно, объяви его.
Так докажи правильность своего утверждения с помощью логики, а не с помощью демагогии и хамства. Пока же ты пытаешь выдать за логику свои предпочтения.
IT>>Пока я не видел ни одного объяснения. ОК>Отказался увидеть.
Пока кроме предпочтений ничего не увидел. Если я тебя попрощу вот прямо сейчас повторить свои аргументы, ты в соостоянии это будешь сделать?
IT>>Кури вывод типов как концепцию. А ещё лучше возьми, например, Немерле и поработай на нём хотя бы пару месяцев. Такие вопросы по for как ты задаёшь отпадут сами собой. ОК>Не считай других глупее себя! Ты вбил себе в голову две вещи.
Всё же ты явно нарываешься. Завязывай с хамством. Тем более, что это не делает тебя умнее.
ОК>Первая. Вывод типов это круто и поэтому надо везде его использовать.
Где я это утверждал?
ОК>Вторая. Ты решил что я не знаю что такое вывод типов и что такое вар в Шарпе и соответственно приплел в разговор хотя речь была совсем не о выводе типов а о том где и как использовать контекстно-ключевое слово вар. То что это вывод типов к изначальному "вопросу" никакого отношения не имеет.
var к выводу типов имеет самое непосредственное отношение. Жаль, что ты этого не понимаешь.
ОК>И да, кроме этого твоего вывода типов, я так и не услышал чем же хороши вар в контексте объявления того же счетчика (вместо явного написания инта).
Вообще-то это ты нам собирался рассказать, что плохого в var. Объективно и чётко, без предпочтений, демагогии и хамства.
ОК>Вопросов по поводу вара у меня нет. Перефразируя тот "вопрос," я скажу что вар в тех двух объявлениях нифига не нужны.
Ещё раз повторяю — это твои личные предпочтения. Логики в этом твоём утверждении ровно ноль.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>>>И что ? Чем это лучше I>>>>Тем, что на С++ ? EP>>>А где я говорил, что это чем-то лучше, круче? Ты спрашивал про аналог I>>Договорились — ничем не лучше Не ясно, с чем же ты раньше спорил
EP>Дискуссия действительна приняла интересный оборот
I>И это всего лишь либа. Тебя же все тянет сравнивать языковые возможности с конкретной либой. И что это покажет ? Эдак одна либа на ассемблере может зарулить весь Хаскель с плюсами и даталогом в минуса.
В том то и дело что не всё что угодно можно реализовать в либе, а только то, что позволяют конструкции языка. Например написать Boost.Spirit на C# просто не реально. Причём как по скорости, так и по синтаксису.
Ну или в нашем конкретном случае, ты не сможешь написать код полностью подобный моему в C#, т.к. там реализация асинхронности обязательно резко возвращает управление из функции после вызова await. В то время как с нормальными coroutines это совсем не обязательно.
I>еще раз у тебя 5 паралельных тасков, каждый из которых асинхронный, из двух цепочек. Сколько цепочек, вообще не важно. Одна, две три — нет разницы. Это понятно ?
Ну так если разницы нет, то в чём проблема была показать код? ) У меня уже был КОНКРЕТНЫЙ пример на C++ и я хотел в точности соответствующий ему аналог на C#.
I>Я показал тебе другой фокус — как ожидать таски, которые ты запускаешь. В твоем коде этого нет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>когда получит управление код после getline ? Ну, например, если сделать вот так I>>
I>>getline(client_stream, msg);
I>>SendMessage(hwnd,WM_SET_TEXT,msg, NULL); // когда сюда придет управление
I>>
EP>Управление придёт после того как msg прочитается из stream'а.
А где же асинхронщина ? Предположим, это единственный код в приложении, а чтение из стрима занимает 5 минут. Итого — асинхронщина, в твоем понимании, это зависание UI на 5 минут.
I>>Покажи мне эту самую асинхронщину. EP>Вся "асинхронщина" спрятана внутри TcpStream.
Здравствуйте, alex_public, Вы писали:
_>В том то и дело что не всё что угодно можно реализовать в либе, а только то, что позволяют конструкции языка. Например написать Boost.Spirit на C# просто не реально. Причём как по скорости, так и по синтаксису.
По синтаксису вполне реально — либо через перегрузку операторов, либо через expression trees. Но да, в обоих случаях будет много динамики.
Здравствуйте, alex_public, Вы писали:
_>В том то и дело что не всё что угодно можно реализовать в либе, а только то, что позволяют конструкции языка. Например написать Boost.Spirit на C# просто не реально. Причём как по скорости, так и по синтаксису.
Написать просто что бы написать а требования к производительности взяты от балды ? Цель какая у этой задач ?
_>Ну или в нашем конкретном случае, ты не сможешь написать код полностью подобный моему в C#, т.к. там реализация асинхронности обязательно резко возвращает управление из функции после вызова await. В то время как с нормальными coroutines это совсем не обязательно.
Нормальных короутин в С++ нет и быть не может, они поддерживаются либой. Это понятно ?
Если таки речь про либу и патчить стек это нормально, то в дотнете, как и в джаве, никто не мешает сделать вот так https://code.google.com/p/coroutines/
Это собственно аналог boost.coroutines.
"там реализация асинхронности обязательно резко возвращает управление из функции после вызова await"
Это и есть асинхронность. Если управление не возвращать, асинхронности не получится. Как то так.
I>>еще раз у тебя 5 паралельных тасков, каждый из которых асинхронный, из двух цепочек. Сколько цепочек, вообще не важно. Одна, две три — нет разницы. Это понятно ?
_>Ну так если разницы нет, то в чём проблема была показать код? ) У меня уже был КОНКРЕТНЫЙ пример на C++ и я хотел в точности соответствующий ему аналог на C#.
У меня нет никакого желания изыскивать задачу под цель. Не можешь выдать эту задачу — так и пишь.
I>>Я показал тебе другой фокус — как ожидать таски, которые ты запускаешь. В твоем коде этого нет.
_>Как раз именно это он и делает. )))
У тебя запускается 5 паралельных тасков. Покажи цитатой из кода ожидание именно этих пяти тасков, а не тех, что внутри этих пяти.
Здравствуйте, Ikemefula, Вы писали:
EP>>Управление придёт после того как msg прочитается из stream'а. I>А где же асинхронщина ?
У тебя какое-то плоское представление о мире.
I>Предположим, это единственный код в приложении, а чтение из стрима занимает 5 минут. Итого — асинхронщина, в твоем понимании, это зависание UI на 5 минут.
Не будет зависания — до прихода данных из стрима управление передаться в другое место. Если там UI — то в UI loop
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Управление придёт после того как msg прочитается из stream'а. I>>А где же асинхронщина ?
EP>У тебя какое-то плоское представление о мире.
Ты хочешь показать асинхронщину "где то то там", а я прошу "где то здесь"
I>>Предположим, это единственный код в приложении, а чтение из стрима занимает 5 минут. Итого — асинхронщина, в твоем понимании, это зависание UI на 5 минут.
EP>Не будет зависания — до прихода данных из стрима управление передаться в другое место. Если там UI — то в UI loop
В какое другое ? Или короутина такая умная, что пороется в адресном пространстве процесса и скажет "О, пока я буду спать, пусть повыполняется вот этот кусочек кода" и некоторым чудом окажетс так, что этот некоторый кусочек кода и будет тем который мне нужен ?
Покажи весь код, для полноты картины. Если UI loop и короутина работают асинхронно, покажи именно эту асинхронщину. Ну и до кучи покажи как руками написать метод навроде getline.
IT>>>Вообще-то я ещё никак не выразил своё отношение к var. Я лишь спросил у тебя что плохого в var, но внятного ответа пока так и не услышал. ОК>>Ну начинаются эти виляния! Хорошо, поделись своим отношением к вар явно.
IT>Зачем? Я не пытаюсь никого не убедить, не разубедить, что var это хорошо или плохо. Этим тут ты у нас занимаешься. Вот и объясни, почему ты так считаешь. Пока же ты плавно скатываешь в демагогию.
Ты обвиняешь меня в демагогии! Однако сам разводишь тут воду. Почему ты не можешь ответить на конкретно поставленный вопрос? И чего же ты тогда ввязался в эту дискуссию?
IT>>>Да пофиг что там было. Там был счётчик цикла, остальное не важно, в том числе и тип этого счётчика. ОК>>Все важно. Если тип слишком маленький, то может возникнуть переполнение, к примеру.
IT>Если тип слишком маленький, то ты получишь предупреждение от компилятора или решарпера.
Возможно.
IT>>>Зачем тебе видеть её тип? Вот знаешь ты теперь, что тип этой переменной int и что это тебе даёт? Только объективно, а не "мне хочется знать".
ОК>>Нету такой вещи как "variable in isolation." Ты работаешь с переменной, тебе нужно знать какие значения она может принимать, ты можешь ее послать в метод или вернуть из метода (а в объявлении метода тебе нужно будет все-таки указать типы!), тебе нужно знать какие методы на ней можно вызвать и наконец ты можешь написать так:
IT>Зачем мне это всё знать?
ОК>>То есть (ошибочно) будешь думать что компилятор выведет один тип а на деле выведет другой.
IT>Здесь ты получишь предупреждение.
Возможно но ты смотри в контексте большей задачи.
IT>>>Это самый натуральный мусор. Для понимания сути алгоритма типы не важны. Важны возможные действия на данными, например, возможность инкрементирования и использования в качестве индекса в примере с for. Это хорошо подтверждается функциональнами языками, которые по своей выразительности кода внутри метода далеко опережают традиционные языки, в том числе за счёт развитой системы вывода типов.
ОК>>Что бы ты не говорил, человек все равно мысленно работает как компилятор.
IT>Это заблуждение.
С твоей стороны?
ОК>>Глядя на код, человек держит в уме типы переменных т.к. типы и определяют алгоритм. Что происходит здесь? Медленный линейный поиск по массиву или быстрый look-up в HashSet-e?
IT>И зачем мне здесь типы? Большинство подобных алгоритмов вообще generics.
Дженерик это когда ты можешь поменять тип в контейнере но не когда ты меняешь сами контейнеры. Конечно, ты можешь это скрыть за каким-нибудь методом, но в самом низу все равно будет-то проход по массиву или лукап в сете.
IT>>>тип параметра x и тип возвращаемого значения выводятся автоматически. ОК>>Я не уверен что ты понял меня. Ты вырезал часть диалога. Речь шла об ограничениях контекстно-ключевого слова вар.
IT>Если ты имел ввиду что-то другое, то либо ты невнятно сформулировал, либо у тебя каша в голове
Я все нормально сформулировал.
ОК>>Ну вывод типов и вывод типов! Что, только потому что "вар это вывод типов" его следует пихать направо и налево? Несколько странный аргумент. Ты еще начни закатывать глаза и простирать руки к небу: "о, вывод типов!"
IT>Похоже ты скатываешься не только в демагогия, но и в хамство. Не советую.
А по делу есть что сказать? Пока что я от тебя только слышу вывод типов да вывод типов!
ОК>>Напомню что речь шла о том что если можешь объявить тип явно, объяви его.
IT>Так докажи правильность своего утверждения с помощью логики, а не с помощью демагогии и хамства. Пока же ты пытаешь выдать за логику свои предпочтения.
Демагогия и хамство это с твоей стороны. Я уже привел не один пример. Ты еще ни одного не привел почему вар в коде это хорошо. Ну и Майкрасофт тоже выразила свою позицию относительно вар, которую я также привел. И да, с твоей стороны я тоже не вижу ни малейшего намека на логику.
IT>>>Пока я не видел ни одного объяснения. ОК>>Отказался увидеть.
IT>Пока кроме предпочтений ничего не увидел. Если я тебя попрощу вот прямо сейчас повторить свои аргументы, ты в соостоянии это будешь сделать?
Боюсь мы впадем в бесконечный цикл. И ты, будь добр, приведи аргументы почему вар везде в коде это хорошо.
IT>>>Кури вывод типов как концепцию. А ещё лучше возьми, например, Немерле и поработай на нём хотя бы пару месяцев. Такие вопросы по for как ты задаёшь отпадут сами собой. ОК>>Не считай других глупее себя! Ты вбил себе в голову две вещи.
IT>Всё же ты явно нарываешься. Завязывай с хамством. Тем более, что это не делает тебя умнее.
Тебе не кажется что хамство исходит от тебя? Нет, вижу, что не кажется.
ОК>>Первая. Вывод типов это круто и поэтому надо везде его использовать.
IT>Где я это утверждал?
А зачем ты сюда приплел вывод типов? Ясно ведь что такое вар в Шарпе и речь совсем не о концепциях была.
ОК>>Вторая. Ты решил что я не знаю что такое вывод типов и что такое вар в Шарпе и соответственно приплел в разговор хотя речь была совсем не о выводе типов а о том где и как использовать контекстно-ключевое слово вар. То что это вывод типов к изначальному "вопросу" никакого отношения не имеет.
IT>var к выводу типов имеет самое непосредственное отношение. Жаль, что ты этого не понимаешь.
Который раз уже. Речи вообще не было об этой концепции. Речь была о том, что если можешь написать тип явно, напиши его. А теперь, будь добр, объясни для чего ты сюда приплел вывод типов.
ОК>>И да, кроме этого твоего вывода типов, я так и не услышал чем же хороши вар в контексте объявления того же счетчика (вместо явного написания инта).
IT>Вообще-то это ты нам собирался рассказать, что плохого в var. Объективно и чётко, без предпочтений, демагогии и хамства.
Я это и сделал. Со своей стороны я попросил объяснить что же хорошего в вар, но ты развел демагогию по этому поводу да еще и пользуешься тут своим статусом.
ОК>>Вопросов по поводу вара у меня нет. Перефразируя тот "вопрос," я скажу что вар в тех двух объявлениях нифига не нужны.
IT>Ещё раз повторяю — это твои личные предпочтения. Логики в этом твоём утверждении ровно ноль.
Логика-логика. Мне математически что ли доказать почему чрезмерное злоупотребление вар это плохо? И это, повторюсь, официальная позиция Майкрософта с которой я согласен.
Не ясно, с чем же ты раньше спорил 
Если нам не помогут, то мы тоже никого не пощадим.
