Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>И где здесь высокоуровневый подход?
EP>define высокоуровневый. только тот что вшит в язык?
Это значит качественные абстракции. то есть, ты пишешь собтсвенно логику задачи, а не используешь примитивы железа или операционной системы.
Если в твоих абстрациях куча указателей, ручной контроль памяти и ручное связывание — это низкоуровневый код, потому что ни одна пользовательская задача не формулируется в терминах массивов, ручного контроля, связывания, указателей и тд и тд.
Здравствуйте, Ikemefula, Вы писали:
I>>>Вот когда такой код появится в прошивке, драйвере файловой системы или движде базы данных или веб сервере, вот тогда и можно будет производительность сравнивать. C>>А он там есть. Большое managed-приложение съест кучу памяти, оставив меньше места под кэш. I>Гипотетический случай. Утечки и ошибки с указателями в С++ дают куда больше реальных проблем.
На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи).
Здравствуйте, Cyberax, Вы писали:
C>>>А он там есть. Большое managed-приложение съест кучу памяти, оставив меньше места под кэш. I>>Гипотетический случай. Утечки и ошибки с указателями в С++ дают куда больше реальных проблем. C>На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи).
Надо полагать косяки и утечки оставляют специально для меня.
Здравствуйте, Ikemefula, Вы писали:
C>>>>А он там есть. Большое managed-приложение съест кучу памяти, оставив меньше места под кэш. I>>>Гипотетический случай. Утечки и ошибки с указателями в С++ дают куда больше реальных проблем. C>>На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи). I>Надо полагать косяки и утечки оставляют специально для меня.
Ну не знаю, если пишешь код на С++ сам — то смотреть радиус кривизны своих рук. Если пишет команда, то применять ипатьевский метод.
Здравствуйте, Ikemefula, Вы писали:
EP>>Сферического "интенсивного заиспользования" java'ы за десяток сообщений ты так не показал — всё, уже не интересно. I>Джавый я как то не мог обещать показать, ибо на ней сроду не писал.
EP>>Как пример — эти аллокации вылезают по всему коду, <b><u>при простейших абстракциях</u></b> — просадка 16x на ровном месте.
I>Такой код в своём уме никто не пишет, кроме вчерашних плюсовиков, которые не знают как устроена память.
[...]
I>С такими проблемами как ты показал, не надо бороться против языка, наоборот, его надо интенсивно использовать.
?
Или в твоём понимании "интенсивно использовать язык" = "сменить его на C#"?
Здравствуйте, Ikemefula, Вы писали:
I>>>И где здесь высокоуровневый подход? EP>>define высокоуровневый. только тот что вшит в язык? I>Это значит качественные абстракции. то есть, ты пишешь собтсвенно логику задачи, а не используешь примитивы железа или операционной системы. I>Если в твоих абстрациях куча указателей, ручной контроль памяти и ручное связывание — это низкоуровневый код, потому что ни одна пользовательская задача не формулируется в терминах массивов, ручного контроля, связывания, указателей и тд и тд.
Здравствуйте, Олег К., Вы писали:
IT>>Это твои личные предпочтения. ОК>Я точно также могу сказать: это твои личные предпочтения!
Вообще-то я ещё никак не выразил своё отношение к var. Я лишь спросил у тебя что плохого в var, но внятного ответа пока так и не услышал.
ОК>Конкретно там был инт потому что у лонговых литералов в конце суффик "Л."
Да пофиг что там было. Там был счётчик цикла, остальное не важно, в том числе и тип этого счётчика.
ОК>На счет шортов не помню но это очень даже хорошо что ты упомянул эти типы поскольку ты, человек, глядя на эту конструкцию не смог сказать истинный тип переменных. Мелочь? Возможно. Но я за то чтобы глядя на переменную сразу видеть ее тип.
Зачем тебе видеть её тип? Вот знаешь ты теперь, что тип этой переменной int и что это тебе даёт? Только объективно, а не "мне хочется знать".
ОК>Кстати, что там покажет Интеллисенс если навести мышку на переменную объявленную как вар?
Подведи и посмотри.
ОК>По мне, так это не мусор а получше чем писать вар. Возможное исключение: всякие "вложенные" дженерики. Ну и для линка, конечно же.
Это самый натуральный мусор. Для понимания сути алгоритма типы не важны. Важны возможные действия на данными, например, возможность инкрементирования и использования в качестве индекса в примере с for. Это хорошо подтверждается функциональнами языками, которые по своей выразительности кода внутри метода далеко опережают традиционные языки, в том числе за счёт развитой системы вывода типов.
IT>>Не знаю. Какие? ОК>Да они только для локальных переменных. Например их нельзя использовать в качестве параметров и return type-а у методов и нельзя использовать в качестве членов класса. Если первое объяснимо, то я не могу предположить ничего на счет второго. По крайней мере на ум ничего не приходит в данный момент. То есть получаются какие-то "кастраты."
Вывод типов прекрасно работает на уровне параметров и возаращаемых значений. Вот пример:
...Select(x => x.ToString())
тип параметра x и тип возвращаемого значения выводятся автоматически.
Вывод типов на уровне методов широко обсуждался в форуме Nemerle. В результате пришли к выводу, что вывод типов на уровне методов может легко привести к ситуации, когда интерфейс классов и целых компонентов может зависеть от внутренней реализации методов, что неизбежно приведёт к непредсказуемым ломающим изменениям. В результате от вывода типов на уровне методов решили отказаться. Думаю, с C# ситуация обстоит аналогичным образом.
ОК>Я не говорил "придумали." Я сказал "ввели в язык" но да, это все для линка было сделанно было в конечном итоге. Как побочный результат, можно использовать вар для "вложенных дженериков" но уж точно не считаю что вар стоит использовать для интов или простых классов как в твоем примере.
Ещё раз. var может быть и сделан для Linq, но по сути это реализация простенького вывода типов, известного уже давным давно в функциональных языках. Только в ФП вывод типов гораздо мощней. В них типы могут выводится из использования, а var — это вывод типов из инициализации. Если тебе хочется понять преимущества и недостатки вывода типов, то тебе нужно его рассматривать не в узких рамках "for (var i=...", а попытаться осознать всю концепцию и уже потом делать выводы.
IT>>С тебя всё ещё один — что объективно плохого в var? ОК>Объясняю это на протяжении нескольких постов.
Пока я не видел ни одного объяснения.
ОК>Плохого в них ничего нет но их не создавали чтобы девелоперы использовали их налево и направо. Теперь ты объясни мне что в них хорошего (кроме анонимных типов и вложенных дженериков). Я пока что не услышал ответа.
Кури вывод типов как концепцию. А ещё лучше возьми, например, Немерле и поработай на нём хотя бы пару месяцев. Такие вопросы по for как ты задаёшь отпадут сами собой.
ОК>Ну и немного не по теме. var — contextual keyword. Могли бы уж и зарезервировать его полностью. А то коряво как-то. Ровно также как и с value в пропертях.
Это к Хейльсбергу.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>А в случае ошибки выкинуть messagebox? Думаешь из non-ui thread это хорошая идея? G>Да и откуда известно что ты там делать будешь? Просто status code сравнить или что-то сложное.
G>Как раз по умолчанию все маршалить UI поток для обработки — хорошая идея. Отключается одной функцией если ты пишешь либу.
Не о том речь. В данном примере можно было всё сделать в один асинхронный вызов, а не в два. И это существенно меняет ситуацию. А messagebox естественно в ui потоке, но после отработки всего асинхронного кода.
G>Если без проблем повторяется, то повтори. Только не скрывай важные детали. G>Интереснее всего увидеть как осуществляется прерывание метода и передача данных. и как это все работает в реальном окружении (обработка нажатий конопок в интерфейсе). G>Ибо твои boost.coroutines скорее всего ни один UI-Фреймворк не поддерживает.
Естественно тут выглядит пострашнее чем C# вариант, но я думаю что ни у кого нет сомнений, что в C++ (с его возможностями переопределения) это можно упаковать в такой синтаксический сахар, что будет ещё намного красивее чем в C#. Evgeny.Panasyuk уже отлично показал это. А я здесь показал именно все внутренности, как и заказывали.
Ну и да, чтобы это всё работало надо вставить в цикле обработки сообщений UI потока (обычно во всех GUI библиотеках заложен обработчик OnIdle — как раз подходящее место) пару строк:
Но эта пара строк нужна одна на всё предложение — думаю не очень тяжёлая цена за реализацию этой вашей async/await модели.
Но как я уже говорил лично мне абсолютно не нравится подобная модель. Я предпочитая что-то вроде эрланговской. На мой взгляд это более логично структурирует код и одновременно избавляет от всех классических проблем синхронизации. Вот этот данный пример (только обрабатывая EnsureSuccessStatusCode не в ui потоке) я бы записал приблизительно так:
Оно конечно чуть более многословно... Но зато и намного проще и расширяемо. Ну и кстати эффективнее с точки зрения производительности, хотя в таких задачах это обычно не важно.
G>Что ты имеешь ввиду под http-сервером? Штуку которая принимает http запрос и отдает ответ или штуку которая принимает http запрос и передает управление другому модулю? G>Если второе, то таких нет по историческим причинам. Все промышленные серверы написаны давно, причем IIS например имеет часть в ядре, так что C# туда не пролезет. G>Другое дело что это довольно малая часть всего конвеера обработки запросов, гораздо большая часть в том же IIS — asp.net, который 100% на .NET
Ой, вот только не надо отмазок. С учётом того, какую часть компьютерных ресурсов человечества потребляют http серверы и базы данных, думаю что даже 5% увеличения быстродействия при переписывание на C# хватило бы для мотивации переписывания ВСЕХ серверов и баз данных вообще. Однако мы этого не наблюдаем. А наблюдаем обратную картинку, что когда упираются в быстродействие, то идут переписывать на C++. Так что не на тут мифы плодить.
Здравствуйте, Ikemefula, Вы писали:
I>Проверка успешности вызова делается там, где нужно. Часто именно вызывающий код имеет все необходимое для такой обработки. Если делать как ты предложил, придется маршалить весь контекст, который очень часто привязан к потоку. Это необязательно UI, это может быть просто любой объект, который привязан к потоку. Почему именно так — да хрен его знает, спрашивай тех ребят, который писали многопоточность на православном С++ под вындоус тот же
Мы вообще то говорим не про какой-то абстрактный случай, а про вполне конкретный пример. И я абсолютно не вижу в данном случае никакой привязки к ui потоку у результата http вызова. Так что не надо отмазок — там код явно искусственно заточен под демонстрацию C# фишки. Но это заточка настолько кривая, что бросается в глаза.
I>ASP.NET в IIS на С#, аналогичные вещи есть и в джаве и тд и тд и тд. Весь сервер никогда не пишется полностью на менеджед, в основном потому что обчно это завязано на ядро, то есть, нет внятного интерфейса для менеджед кода.
Дааа? ) Ой, как интересно. И что там в реализации http сервера завязано на ядро? ) Хорошо бы на примере nginx... Он как раз с относительно небольшими исходниками, а при этом занимает второе место после апача среди активных сайтов и применяется обычно на самых нагруженных...
Здравствуйте, Ikemefula, Вы писали:
I>Это значит качественные абстракции. то есть, ты пишешь собтсвенно логику задачи, а не используешь примитивы железа или операционной системы. I>Если в твоих абстрациях куча указателей, ручной контроль памяти и ручное связывание — это низкоуровневый код, потому что ни одна пользовательская задача не формулируется в терминах массивов, ручного контроля, связывания, указателей и тд и тд.
Это вообще не подходит ни под один язык общего назначения. Только под DSL. )))
И ещё по поводу сайтов и серверов. Сайт rsdn же у нас кажется как раз на .net работает? ) Том самом высокуровневом, в котором не надо ничего руками отслеживать... Да и т.к. это программистский ресурс, то уж наверняка сайт написан не криворукими новичками... Интересно тогда, а почему заходя на форум, я периодически вижу такую страничку:
Внутренняя ошибка сервера
URL: /Forum/Main.aspx
Transaction (Process ID 74) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Здравствуйте, alex_public, Вы писали:
I>>Это значит качественные абстракции. то есть, ты пишешь собтсвенно логику задачи, а не используешь примитивы железа или операционной системы. I>>Если в твоих абстрациях куча указателей, ручной контроль памяти и ручное связывание — это низкоуровневый код, потому что ни одна пользовательская задача не формулируется в терминах массивов, ручного контроля, связывания, указателей и тд и тд.
_>Это вообще не подходит ни под один язык общего назначения. Только под DSL. )))
Здравствуйте, alex_public, Вы писали:
_>Мы вообще то говорим не про какой-то абстрактный случай, а про вполне конкретный пример. И я абсолютно не вижу в данном случае никакой привязки к ui потоку у результата http вызова. Так что не надо отмазок — там код явно искусственно заточен под демонстрацию C# фишки. Но это заточка настолько кривая, что бросается в глаза.
I>>ASP.NET в IIS на С#, аналогичные вещи есть и в джаве и тд и тд и тд. Весь сервер никогда не пишется полностью на менеджед, в основном потому что обчно это завязано на ядро, то есть, нет внятного интерфейса для менеджед кода.
_>Дааа? ) Ой, как интересно. И что там в реализации http сервера завязано на ядро?
Да, именно так. За подробностями обращайся к сиплюсплюсникам из микрософт
>Хорошо бы на примере nginx... Он как раз с относительно небольшими исходниками, а при этом занимает второе место после апача среди активных сайтов и применяется обычно на самых нагруженных...
Здравствуйте, Cyberax, Вы писали:
C>>>>>А он там есть. Большое managed-приложение съест кучу памяти, оставив меньше места под кэш. I>>>>Гипотетический случай. Утечки и ошибки с указателями в С++ дают куда больше реальных проблем. C>>>На практике (которая есть критерий истины) утечки не являются серьёзной проблемой для С++ и легко обнаруживаются (valgrind со товарищи). I>>Надо полагать косяки и утечки оставляют специально для меня. C>Ну не знаю, если пишешь код на С++ сам — то смотреть радиус кривизны своих рук. Если пишет команда, то применять ипатьевский метод.
Ну вот берем для примера виндовс, жрет памяти не в себя, по поводу и без повода. Надо полагать, в этом виноват дотнет который даже не запущен ?
И получается именно так как ты рассказал — "съест кучу памяти, оставив меньше места под кэш"
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Ikemefula, Вы писали:
I>>>>И где здесь высокоуровневый подход? EP>>>define высокоуровневый. только тот что вшит в язык? I>>Это значит качественные абстракции. то есть, ты пишешь собтсвенно логику задачи, а не используешь примитивы железа или операционной системы. I>>Если в твоих абстрациях куча указателей, ручной контроль памяти и ручное связывание — это низкоуровневый код, потому что ни одна пользовательская задача не формулируется в терминах массивов, ручного контроля, связывания, указателей и тд и тд.
EP>Здесь обсуждается конкретный код, из этого сообщения
EP>Более высокоуровневый, более "собственно логико-задачный", использует меньше примитивов железа и ос, ручного связывания, чем C++1998 код:
Выделил. Нет ручного связывания, как ты видишь, bind нигде не вызывается, а параметры идут куда надо. Явно указано ожидание результата, при чем такой код совершенно не означает что будет какой то джополнительный поток. Всё.
А у тебя ручное связывание аргументов, результатов и явная команда запуска обработки в фоне.
При чем если минимально усложнить код, тебе придется заниматься ручно диспетчеризацией навроде "execute_on_ui_thread"
EP>>>Сферического "интенсивного заиспользования" java'ы за десяток сообщений ты так не показал — всё, уже не интересно. I>>Джавый я как то не мог обещать показать, ибо на ней сроду не писал.
EP>А это что
EP>>>Как пример — эти аллокации вылезают по всему коду, <b><u>при простейших абстракциях</u></b> — просадка 16x на ровном месте.
I>>Такой код в своём уме никто не пишет, кроме вчерашних плюсовиков, которые не знают как устроена память.
EP>[...]
I>>С такими проблемами как ты показал, не надо бороться против языка, наоборот, его надо интенсивно использовать.
EP>? EP>Или в твоём понимании "интенсивно использовать язык" = "сменить его на C#"?
В моём понимании здесь нет ни слова про джаву Код который ты привел, пишут именно вчерашние сиплюсники, силу многолетней привычки "зачем думать и так всё быстро".
Покажи нормальную задачу, в терминах юзера, без использования слов "массив, элемент, индекс".
Я на прошлой работе занимался визуализацией, при чем практически все было самописным — рендеринг, векторная алгебра, трансформации и тд и тд и тд.
Выяснил, что дотнет может справляться с вычислениями быстрее, чем нативная либа с отрисовкой результатов. Тут появляешсья ты и высасываешь из пальца задачу "в цикле по массиву элементов..."
Итого, пока что у нас расклад такой — я привел примеры, где С++ используют без плюсов или даже пишут "против языка", а вот от тебя пока что ничего не было.
P.S. Если всё что ты хотел сказать, это разница во времени при проходе по массиву между C++ и С#, то мог бы и не напрягаться, я сам про это писал на этом форуме, при больше, чем всех твоих сообщений вместе взятых.
_>Естественно тут выглядит пострашнее чем C# вариант, но я думаю что ни у кого нет сомнений, что в C++ (с его возможностями переопределения) это можно упаковать в такой синтаксический сахар, что будет ещё намного красивее чем в C#
Красиво, это когда компилятор умеет связывание рахных сортов. В С# тоже можно все упаковать, притом используя именно поддержку компилятора.
Несетевая логика поскипана, остальной сетевой код коннектится к сокс-серверу и через него шлёт HTTP запрос на другой сервер.
Функции ***_resume выполняются асинхронно. То есть после их вызова корутина спит, а после получения результата возобновляется с того же места. Связь с остальными корутинами — через поля структуры fd. Прервать соединение тоже понятно как.
Функции ***_resume есть мною писанные обёртки над соответствующими функциями asio. Они все однотипные, покажу на примере connect_resume:
struct connect_handler_resume
{
private:
coroutine_t owner_fiber;
boost::system::error_code *ec;
public:
connect_handler_resume(coroutine_t owner_fiber,
boost::system::error_code *ec)
: owner_fiber(owner_fiber), ec(ec)
{
}
void operator()(const boost::system::error_code& ec);
};
// этот код вызовется по завершении операцииvoid connect_handler_resume::operator()(const boost::system::error_code& ec)
{
*this->ec = ec;
co_call(owner_fiber); // здесь возврат в корутину
}
boost::system::error_code connect_resume(boost::asio::ip::tcp::socket &sock,
boost::asio::ip::tcp::resolver::iterator it)
{
boost::system::error_code ec;
connect_handler_resume handler(co_current(), &ec);
sock.async_connect(*it, handler);
/**----------*/
co_resume(); //здесь уходим из корутины и сюда же нас вернёт вызов co_call(owner_fiber);
/**----------*/return ec;
}
Заметьте, этот код писался летом-осенью 2011 года, когда в C# ещё не было await.
Здравствуйте, alex_public, Вы писали:
_>И ещё по поводу сайтов и серверов. Сайт rsdn же у нас кажется как раз на .net работает? )
Очень интересный вопрос. В вебе вечно не хватает ни перформанса, ни памяти. Очень большой и острый вопрос. Казалось бы — надо всё на С++ писать. Но вот шота прогресс пошел целиком и полностью в менеджед — дотнет, джава, питон, руби, пхп, перл и даже джаваскрипт.