Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Мощно и выразительно.
Угу, поэтому foreach по родному дотнетному массиву компилится в код, не использующий итераторы. Достаточно подать тот же массив туда, где ожидается IList<T>, и получаем полный приплызд. Мне удавалось поднять быстродействие более чем в 10 раз в дотнете просто заменяя везде АПИ на интерфейсах на АПИ на массивах. Причем, быстродействие требовалось именно для веб-аппликухи (поиск в семантическом облаке на основе AI).
Здравствуйте, AndrewVK, Вы писали:
MS>>Да элемеентарно. Когда у тебя зоопарк из 15 платформ, C++ это единственно возможный вариант.
AVK>Когда у тебя зоопарк из 15 платформ, скорее подойдет Java.
До 2005-го так и было. Но потом компиляторы С++ как-то стали получше соответствовать стандарту. Прямо на сегодня разработка в исходниках под зоопарк платформ уже не является таким кошмаром, как, скажем, в 99-м году.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>При отсутствии виртуальных методов и тайп-теста (либо его заменителей) мы не сможем работать с subtype-полиморфными данными. А именно это мне требовалось.
V>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут.
А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
V>>>Предположим, что с основными структурами данных я знаком, и даже представляю, как они организуются в функциональной парадигме. У нас же был вполне конкретный вопрос по механике С++ и сравнении возможностей генериков из C#, для какого-то совсем конкретного момента реализации, который не был показан. ИМХО, реализаций любого абстрактного алгоритма может быть гораздо больше одной, поэтому почти всегда можно выкрутиться. S>>Естественно можем, но в случае с C++ придется ослабить типизацию, для того что бы работать с такой структурой в рантайме.
V>Во-первых, не вижу, откуда это следует.
Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
V>Во-вторых, там вообще работа по несчастным Cons, т.е. организации очереди на односвязанном списке, чтобы время доступа к обоим концам было O(n). Сорри, но я на коленке накатаю очередь, которая порвет эту многократно, и уж конечно будет тоже O(n).
Theorem 8.3 snoc and tail run in O(1) amortized time.
Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
V>Бо мутабельный двусвязанный список всех описанных в той работе приседаний не требует... И там такой разный K при этом O(n) получается, что мама не горюй. Посмотри что происходит при двусторонней выборке. В общем, пусть у функциональщиков будут свои тараканы...
По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
V>ИМХО, в основу должны идти не алгоритмы, а требования. А уж алгоритмы берутся те, которые подходящие для инструмента, на котором мы решились эти требования удовлетворить.
В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Отдача статических ресурсов нейтивная, даже в рамках ASP.Net. Работает несоизмеримо быстрее managed-варианта. G>>Ну никакого интереса в статических ресурсах нет. Эра статического инернета закончилась еще 20 лет назад.
V>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере.
По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
V>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился.
Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json. Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
V>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.
Посмотри сколько данный форум возвращает, и не говори бредятину.
V>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом.
Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
V>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++)
Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
V>Ну и даже брать задачи работы с БД, где ASP.Net якобы является "удачной прослойкой"... Дотнетный парсер потока MS SQL сливает нейтивному в 4-5 раз (а то и более, если идет много числовых полей и мало строковых). Т.е. на сегодня ситуация такова, что нейтивный MS SQL способен выдавать данные быстрее, чем дотнетные приложения способны парсить его ответ... Хохма натуральная. Уже на гигабитных картейках в локалке это видно во всей красе.
И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
V>Поэтому действительно "быстрые" веб-сервера пишутся как нейтивная часть некоторого сервера, например модули Apache или нейтивные модули IIS. Так же полно популярных нейтивных либ, вроде этой, обыгрывающих серверную часть HTTP-протокола.
И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
V>Ты просто очень далек от современной ситуации в web, судя по твоим постам...
Зато ты близок... сколько ты вебовых приложений написал то?
G>>Угу, и сразу начинать ругаться на то что "тормозит", "криво работает" итп. G>>WPF прост только с виду, для того чтобы он эффективно работал надо еще постораться.
V>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать...
Плати бабло — сделаю. Мне не сложно.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Начнем с того, что foreach — это фактически аналог readonly итерации... далее, не поверю, что используется только foreach, полно таких алгоритмов в обычной жизни, где foreach не катит. G>>Агащаз.
V>Быстрая сортировка. Нарисуй-ка inplace без foreach.
.Sort
V>>>Например, попарный перебор элементов коллекции. G>>.Zip
V>Опять read-only.
И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание.
V>>>Для использования foreach в этих сценариях надо делать обертки-итераторы, которые (не может быть!) будут так же итерироваться по массивам по поданным извне (что опять?) индексам. G>>Снова бред. Ты просто не в теме. V>Пока что я вижу, что это ты не в теме даже в базовых вещах.
В каких базовых вещах? Ты банально не знаешь как писать на C# и пытаешься писать на нем как на C++, а потом жалуешься. Это и называется "не в теме".
G>>Вообще-то мы о managed говорим. Про stl и boost я знаю. Но они даже рядом с Linq не валялись по мощности и выразительности.
V>На сегодня Linq сливает даже традиционным функциональным языкам по эффективности времени выполнения... а те, в свою очередь, во все времена были руганы за тормознутость и требования к памяти. Да и полно таких технологий, в сравнении с которыми Linq и по выразительности — ничто... Одна засада, тормозит это так же нехило, как и LINQ, а то и похлеще.
Покажи еще хотя бы парочку. Для моих задач быстродействия linq более чем хватает, один раз не хватало, так я просто linq код переписал в C с той же семантикой, прогнал те же тесты и все заработало. Это было около 0.1% кода приложения.
G>>Ты бы лучше выглянул из своей норы, увидел бы что в .NET есть много способов априори избежать тех ошибок, которые постоянно случаются в unmanaged.
V>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов.
Ага, только эта ошибка логики программы проявляется только в unmanaged
G>>Я тоже видел падения, но ты же пытаешься доказать что их не меньше чем для unmanaged, причем приводишь в качестве агрументов ошибки вроде IndexOutOfRange. Вот только в managed можно писать программы на таком уровне абстракции, где подобные ошибки не случаются. V>На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно.
Практика показывает что: а) нельзя, потому что сборщика мусора нет б)не будет эффективнее
V>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно.
Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
V>Слабоватый ты оппонент с такой позицией...
Зато ты сильный
V> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили).
Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex.
Так вот во всех них обычный for крайне редко встречается.
V>>>Я скажу, где дотнет действительно очень помогает. Это вообще в отсутствии юнит тестов. Ведь там, где криворукий С++ программист пройдется по памяти и не проверит конечный результат (хотя бы самый высокоуровневый) через юнит-тесты, там криворукому C#-программисту будет выплюнут эксепшен. Это действительно резко понижает порог вхождения... со всеми вытекающими побочными эффектами для индустрии в целом. G>>Не, в C# такой код просто не будет написан.
V>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить?
Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
G>>Но ты этого не поймешь, потому что даже на C# пишешь как на C++. Вот и получается что для тебя managed это только exception вместо непонятного поведения.
V>А почему я должен понимать твои неуемные фантазии? Я этой ньювасюковщины наелся еще в 2002-м, а потом в 2005-м. Но сужу по реальным проектам, которых насмотрелся достаточно. А ты тут пытаешься говорить "сахар, сахар", и удивляешься, как у нас до сих пор во рту не сладко.
Я же и говорю, ты пишешь на C#, как на C++. Пока не высунешь голову из норы не увидишь что вокруг происходит.
V>Ну так не везде же нужна голая логика без эффективности, правда?
Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности.
V>Иначе бы никто не искал программистов С++ сегодня.
Ищут их в основном для саппорта.
V>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет?
Не пишется, а саппортится, пишется на порядки меньше.
G>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>В каком месте?
например умные указатели с подсчетом ссылок.
G>>Нет, то что не происходт — не проверяется. Нет смысла писать тесты для наборов входных данных, которые не появляются в работе. Лучше такие места заткнуть ассертами (или code contracts), любое срабатывание которых очевидно говорит о баге, который надо править.
V>Вот ты и попался. Я неделю ждал, когда же ты, наконец, проговоришься и назовешь вещи своими именами, без твоих обычных обтекаемых "тут всё ИНАЧЕ!!!". V>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших.
А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
G>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>Детсад.
Правда жизни. Ты много процесс тестирования организовывал?
G>>Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе. V>Детсад.
См выше.
G>>Тем не менее в этом форуме просмотры подсчитываются сразу и нагрузка на этот сайт совсем недетская. V>Потому что не требуется точность
Тем не менее точность есть. Каждый просмотр подсчитывается.
V>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр.
Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Ты их по скорости сравнивал? G>>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет.
V>Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?
В смысле? 10000 раз в секунду пересчитать сумму массива? Данивопрос, посчитаю один раз и верну ответ.
Здравствуйте, vdimas, Вы писали:
V>До 2005-го так и было. Но потом компиляторы С++ как-то стали получше соответствовать стандарту.
Если б дело было только в компиляторах. Это отдельная песня С++ — отсутствие ABI, но это только половина дела. Java обеспечивает стабильный рантайм на почти любой платформе.
V> Прямо на сегодня разработка в исходниках под зоопарк платформ уже не является таким кошмаром, как, скажем, в 99-м году.
Но Java все равно на порядок упрощает создание кроссплатформенного софта.
Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
V>>Ты случайно не клиентскую DHTML-фичу имеешь ввиду? V>>Шучу-шучу... Но по факту, в хорошем современном веб-приложении, особенно с модой на ajax, на клиенте выполняется всяко больше, чем на сервере. G>По факту ты говоришь бред, то что выполняется на клиенте в веб-приложении — логика интефейса, а бизнес-логика на сервере.
Не прав. Первичная бизнес-логика обязательно и на клиенте тоже. Но и это не важно, коль мы обсуждаем динамику и распределение кода в % м/у клиентом и сервером. Абсолютно фиолетово с т.з. обсуждаемого, как ты назвал свой серверный код.
V>>Ну и к тому же, более 90% от современного трафика составляет всё еще статический контент, в т.ч. графика. Поэтому насчет твоих "эра закончилась" — это у тебя от незнания ситуации публичный казус случился. G>Это тут не при чем. Сервер может много ресурсов потратить чтобы выдать относительно небольшой json.
Какой именно сервер? MS SQL? А при чем тут дотнет-то? Это ж нубство натуральное писать такой код, который должен занимать "много ресурсов" управляемого кода. Ты профанируешь тем самым саму суть ASP.Net, которая позиционирует себя как относительно легковесное решение в пересчете на запрос.
G>Один видеофайл будет в миллион раз больше, но пользы от него в миллион раз меньше.
С чего бы это? В бизнесе польза измеряется выручкой, а эффективная отдача медиа находится фактически на грани возможностей современного управления ресурсами. Нейтивного управления, разумеется. В MS над этим голову бьют, стараясь держаться на уровне конкурентов, а некий Вася Пупкин на весь интернет считает, что его прочитанное и показанное лишь спустя секунду поле из базы данных всяко важнее. Весело в тобой.
V>>Да и вообще, размер средней генерируемой HTML-странички, без учета скриптов и стилей (которые статичны у грамотных разработчиков, в отличие от нубов, юзающих server-side web controls) в районе 500 байт. Где там нужна эффективность? Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна. G> G>Посмотри сколько данный форум возвращает, и не говори бредятину.
И что, каждый байт генеренный? Вырежи пользовательские сообщения (статическая часть, которую можно было хоть в файлах хранить) и посмотри еще раз.
V>>И если уж речь зашла об эффективности... где нужна эффективность для "тяжеловесных" операций, там вовсю пашет CGI или FastCGI/С++ аж бегом. G>Приведи пример? Вот stackoverflow с тобой не согласен, а это на сегодня самый быстрорастущий ресурс.
Мде? Покажи мне, в каком месте он не согласен? Нашел ты, однако, "ресурс", который суть текстовый формум. Ты еще социальную сетку какую-нить приведи в пример. Я тебе быстро покажу, как ее реальное быстродействие замерить.
V>>Потому как подобные задачи на дотнете даже не взлетят. Дотнет там можно попользовать разве что вместо PHP-обертки, т.е. в кач-ве "подай-принеси" на этом и всё. (конкретно по ссылке высокоуровневая логика на матлаб, а тяжеловесные вычисления переписаны на С++) G>Не вижу там C++, скорее всего твоя выдумка. Там какойнить PHP и flash.
Т.е. ты не в состоянии ни HTML код страницы прочесть, ни по ссылке сходить?
G>И что же мы не видим копортивных приложений на C++? все как-то java, да .NET или веб на PHP и Ruby. Видимо парсинг TDS далеко не самая большая проблема
Ну конечно, фигли там для нескольких десятков девочек-операционисток попу рвать? Подождут. Если они работали в свое время на Celeron-333, то теперь уж точно ниче страшного. Правда, в те времена ГУИ было честное и быстрое, в отличие от браузерного, но кто и когда этих девочек спрашивал?
G>И много ты таких видел? Я ни одного, все как-то пишут на .NET и не парятся.
Как тебя почитать, так ты окромя дотнета вообще ничего не видел... А я здесь при чем?
По данным Netcraft Web Server Survey за июнь 2011 года, доля веб-сервера Microsoft IIS на всех доменах в Сети продолжила падать и с майских 18,37% опустилась до уровня 16,82%. Это самый низкий показатель с конца 1997 года.
V>>Ты просто очень далек от современной ситуации в web, судя по твоим постам... G> G>Зато ты близок... сколько ты вебовых приложений написал то?
О! Можно вынимать и демонстрировать?
Если за всю карьеру, то около десятка, из них 3 на ASP.Net. Есть с чем сравнить. А если брать не чистый веб, а всякие сервисы, просто многозвенки и распределенные архитекруты по различным протоколам (пару десятков протоколов навскидку), то, скажем так, на конкретно ASP.Net я могу посмотреть со всех сторон. Не только как "чисто-вебной" части, когда принимается решение на чем делать HTTP-часть, но и чуть раньше, как инструмент реализации GUI, когда принимается решение, делать ли веб-морду, или таки классический GUI-клиент. Например, однажды был взят ASP.Net для генерации Silverlight-приложений, которые отображаются во вкладках IE (!!!) локальным сервисом (вовсе не 80-й порт) в плагине к этому IE. Такое решение оказалось намного интересней в плане отзывчивости, чем GUI этого плагина на WPF + локальный WCF сервис. Еще пару раз брал ASP.Net как либу для нетривиального рантайм-редеринга текста (т.е. не как out-of-proc сервер, а именно как либу). Это помимо классического веба. Т.е. эту примочку к IIS раком ставить умеем вдоль и поперек, не переживай... и даже хакать и корректно юзать MS Embedded SQL с ASP.Net, чтобы сравняться по эффективности с MySQL на зачитке (смогешь так?).
Сравнить с аргуентами: "для моих задач хватает", "все пишут на ASP.Net"... и это при ~17% реальной живой доле и отрицательной первой производной.
V>>Не надо говорить о том, о чем не имеешь ни малейшего представления. Вот я тебе пошлю свой вариант прототипа WPF-приложухи имеющей сравнимую сложность GUI. Берешься сделать его заметно эффективнее (заметно, это хотя бы 30%)? А то ля-ля в форуме разводить, это не мешки ворочать... G>Плати бабло — сделаю. Мне не сложно.
Так и думал...
но если уж речь о деньгах, то это имеет смысл только в виде пари, симметричности ради, т.к. мне тоже придется затратить время на макет и некую минимальную функциональность.
Здравствуйте, AndrewVK, Вы писали:
AVK>Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
Сдается мне, тебе просто очень хочется найти в нем проблему, но со знанием предмета не очень. Я не хочу сказать, что проблем нет никаких, но как то уж ты мимо все время тыкаешь, не туда где действительно проблемы имеются.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, gandjustas, Вы писали:
V>>Быстрая сортировка. Нарисуй-ка inplace без foreach. G>.Sort
Не вопрос, приведи ее "рефлекторное" тело и покажи, что там хватило конструкции foreach.
Ты ведь не хочешь быть тем самым "программистом", который, не найдя в и-нете TSuperComponent считает задачу нерешаемой?
V>>Опять read-only. G>И че? Я вообще immutable юзаю, работает в некоторых сценариях быстрее + распараллеливание.
Именно, в очень некоторых быстрее. В которых все остальные тоже юзают. Но где надо действительно быстрее, не катит.
G>В каких базовых вещах? Ты банально не знаешь как писать на C# и пытаешься писать на нем как на C++, а потом жалуешься. Это и называется "не в теме".
Пока ты по-существу не ответил ни на одно замечание по теме, а пытаешься снова и снова обсуждать роль С++ в формировании личности оппонента.
G>Для моих задач быстродействия linq более чем хватает
Дык, может это ключевое? Что же ты пытаешься тогда за всех расписываться?
V>>Да, пошли по 4-му кругу. И за все эти круги так и не было названо более одной unmanaged-ошибки... Потому как вторая названная якобы исключительно unmanaged ошибка — работа с уже удаленным объектом — это есть ошибка логики программы вообще-то, которая на unmanaged себя проявляет сразу, а на managed является той самой классической плавающей головной болью, когда работаем с никому уже ненужными экземплярами объектов. G>Ага, только эта ошибка логики программы проявляется только в unmanaged
Именно, явно проявляется, о чем и речь! А в managed ее надо долго и нудно искать, и вообще сложно воспроизвести, т.к. ошибка дает себя знать не в момент, когда срабатывает ошибочный код, а по косвенным признакам.
V>>На таком уровне абстракции можно на любом языке писать, даже на С++... Всяко эффективней будет все-равно. G>Практика показывает что: а) нельзя, потому что сборщика мусора нет б)не будет эффективнее
При чем тут сборщик мусора и библиотека boost::bind, например? Никакой памяти из кучи не выделяется, и никакой мега-тормозной технологии, типа создания делегатов для однократного вызова, не используется. По моим замерам, стоимость использования boost::bind сравнима со стоимостью вызова обычного метода, в отличие от процедуры создания и вызова делегата (в 5-50 раз дороже, зависит от того, сколько раз был вызван только что созданный делегат).
V>>Ты опять низвеграешься в пучину своей демагогии, что на дтонете надо всё делать правильно, и тогда будет просто супер, а на С++ обязательно надо делать неправильно. G>Ты до сих пор не понял, в unmanaged больше возможностей сделать ошибку. В managed можно писать так что подобные ошибки в принципе исключаются.
Мы пока обсудили всего две ошибки, причем, характерная для native всего одна из них (и то не факт, при таком как у вас тестировании).
V>> Тем более, что бери любой опен-сорсный C#-проект, и смотри как реально пишут (если уж опенсорс по плюсам тут приводили). G>Я вот активно юзаю опенсорсный Orchard CMS, хорошо пишут. Еще для SharePoint юзаю несколько проектов с codeplex. G>Так вот во всех них обычный for крайне редко встречается.
Крайне редко, это сколько в абслютном кол-ве? Обложен ли каждый случай минимум 3-мя юнит-тестами, т.е. включающими граничные случаи?
V>>Да ну? Даже внутри "святой коровы" самих дотнетных либ, идущих в поставках .Net? Ты о рефлекторе слышал когда-нить? G>Вообще-то можно и исходники скачать. Я вот Linq и Rx смотрел, так там в принципе отсутствует код, аналог которого в unmanaged может падать.
Если смотрел так же как стандарт ECMA-335, значит не смотрел вообще. В телах реализации системных либ дотнета массивы используются чуть более, чем везде. К тому же, ты назвал либы, доля которых менее 1% в общей кодовой базе в поставке, но и там есть операции над массивами и по индексу в т.ч. Посмотри еще раз.
G>Есть два вида эффективности: высокая эффективность и достаточная эффективность. Так вот первая нужна только программистам чтобы понты на форумах кидать, а вторая нужна бизнесу.
Это ты только что сам придумал? Вообще-то, эффективность нужна "лучше, чем у конкурентов", чтобы продавать коробочное ПО. И даже в заказном ПО при условии честных тендеров, как ни странно, тоже.
G>У меня был ровно одни случай когда .NET не обеспечивал достаточной эффективности.
Действительно? Это лишь значит, что ты в отрасли совсем недавно и больше ничего.
V>>Иначе бы никто не искал программистов С++ сегодня. G>Ищут их в основном для саппорта.
Нет.
V>>Подумай сам, нафига пишут огромное кол-во нейтива, ведь есть джава и дотнет? G>Не пишется, а саппортится, пишется на порядки меньше.
Опять мимо.
G>>>При этом способы работы, которые уменьшают количество таких ошибок, приводят к снижению быстродействия.
V>>В каком месте? G>например умные указатели с подсчетом ссылок.
Такие указатели используются (1) редко в коде, (2) редко в рантайм, обычно для самых высокоуровневых объектов, которые живут практически столько же, столько и вся программа. Для оперативных данных это используется разве что на этапе макетирования или когда некритично быстродействие. Т.е. когда твой аргумент не работает.
V>>Что и требовалось доказать... А по другому и быть не могло, с таким пещерным представлением о процессе тестирования ПО... По-сути, ты предлагаешь сваливать на клиента хлопоты по поиску ваших багов. Потому как ассерты — вещь исключительно динамическая. Мои поздравления. Никаких "волшебных ИНАЧЕ", как только что выяснилось выяснилось, нет и никогда не было. А есть обычная практика небольших контор, питающихся за счет несложного заказного ПО. Главное, надыбать клиента и можно окучивать до бесконечности. Но на рынке коробочного ПО подобные рассуждения выглядят как рассуждения сумашедших. G>А с чего ты взял что ассерты заменяют другие виды тестирования? Ассерты заменяют только те самые "негативные" тесты. Не надо описывать такие сценарии в автотестах. Пусть code contracts занимается проверкой что они не произойдут.
Угу, ЧТД повторно. Свалить в кучу ассерты и контракты — это жесть, спасибо за море фана.
Ассерты должны искать ошибки самой программы, в то время как контракты — проверять допустимость аргументов, которые бывают любые, даже в программе без ошибок.
Ассерты сами по себе ничего не проверяют, это не статическая, а динамическая штука. Ты напишешь проверку — будут у тебя проверять, не напишешь — будут проверять у клиента.
G>>>Ты совсем не понимаешь для чего нужны автоматизированные тесты. Найти ошибку тестами крайне сложно, потому что ты пишешь тесты, тестируя ожидаемое поведение. Но поведение может оказаться совсем неожиданным, например если кто-то в процессе работы меняет часовой пояс. Стоит ли для такого писать тест? Что может программа предпринять в таком случае? А ничего и тест писать не стоит. V>>Детсад. G>Правда жизни. Ты много процесс тестирования организовывал?
Дык, нет у вас собственно процесса. Самодеятельность одна, основанная на субъективных представлениях о том, "как надо". Сорри, но к теме "качество ПО" и организации контроля ка-ва ПО ты пока в своей карьере еще не приближался.
G>>>Если же ты пишешь алгоритм, который работает на определенном классе входных данных, то какой смысл писать тест для данных, не входящих в этот класс? Нужно воткнуть assert и проверять что вызывающий код генерирует входные данные в нужном классе. V>>Детсад. G>См выше.
Ну что смотреть-то? Неужели нельзя хоть немного подумать самому, уже ведь все входы и выходы показал. Ты же абсолютно правильно всё написал в начале абзаца, только надо обязательно уточнить, что сей алгоритм доступен только как "private" в таком сценарии, и на него не делаются публичные бинды, типа подписки на события или просто возвращения наружу делегатов. Это принципиально! Ну а потом скатываешься на натуральную ересь, потому как проверять твой assert без негативных тестов смогут только клиенты. Нафига же ты его ставил? Да еще, в зависимости от используемой технологии ассертов, их или не будет в Release-конфигурации, т.е. понеслась любимая всеми плавающая ошибка, или они будут, но плюнут в клиента самое неудобочитаемое для него сообщение (это залет, курсант!). И что о вас подумают люди? Не надо так подставлять свою контору.
G>Тем не менее точность есть. Каждый просмотр подсчитывается.
Это не есть точность, если не каждый фиксируется в базе. Например, сбойнет чего-то на серваке и часть значений по последним полностью законченным сеансам пропадет. Здесь не страшно, но в финансовой сфере, к примеру, это недопустимо.
V>>Да и нагрузка тут — не сотни тыщ запросов в секунду, так что даже если сбрасывать каждое приращение в базу — ниче страшного не будет. Это не тот порядок цифр. G>Это очень высокий порядок цифр, для большинства приложений и такой не нужен.
Да понятно, кто над чем работает, у того такие представления. Мне всё время охота сказать, что "большинству нужен", но я прекрасно понимаю что это не так, або биография была бурная, делал даже автоматизацию офиса, поэтому ограничиваюсь фразой "много где нужен"...
Интересуйся больше окружающим, сходи на другие разделы этого же форума, например. Хотя бы в multimedia.
Здравствуйте, DarkGray, Вы писали:
V>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>при отрицательной относительной(долевой) первой производной
V>>>и это при ~17% реальной живой доле и отрицательной первой производной.
DG>>при отрицательной относительной(долевой) первой производной
V>Разумеется, коль приведены проценты.
я о том, что уменьшение доли может ни о чем не говорить, если при этом увеличивается абсолютное кол-во.
такое поведение может быть обусловлено тем, что технология применяется в какой-то нише, которая хоть и растет, но медленнее чем другие ниши.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Вот в этом как раз и проблема продвижения дотнета: если бы Mono, если бы MS, если бы Гарретт, если бы Синофски, если бы Баллмер, если бы... И ещё сто тысяч "если бы" и "завтра".
AVK>Сдается мне, тебе просто очень хочется найти в нем проблему, но со знанием предмета не очень.
Ну сдаётся, так сдаётся.
AVK>Я не хочу сказать, что проблем нет никаких, но как то уж ты мимо все время тыкаешь, не туда где действительно проблемы имеются.
Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
Тебе? Не буду. Упражнения в демагогии, уж извини, в мои ближайшие планы не входит. А интереса к реальному положению дел, судя по этому топику, у тебя нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 1537 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Отлично. У тебя есть шанс меня поправить — покажи, где по твоему мнению, проблемы имеются.
AVK>Тебе? Не буду. Упражнения в демагогии, уж извини, в мои ближайшие планы не входит. А интереса к реальному положению дел, судя по этому топику, у тебя нет.
Но тем не менее ты ей занимаешься. Например, сознательно смешивая ответ лично мне и комментарий на публичном форуме.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, samius, Вы писали:
V>>Это зависит от способа обхода целевого мн-ва. Иногда целевым является именно шаблонный код обхода, который оперирует разными типами, но находящимися в похожих отношениях. Ведь обход для целей визитора бывает внешний и инкапсулированный, это прямо в паттерне сказано. В случае инкапсулированного обхода необязательно всем элементам мн-ва быть наследником одного базового класса/интерфейса, это может быть лес независимых иерархий. Так вот, виртуальная точка входа для callMeBack() реально нужна только в том узле, реальный тип которого неизвестен. Тут уж, конечно, полиморфизм + DD помогут. S>А я и пишу про случай, когда реальный тип неизвестен. И virtual generic метод тут очень кстати.
Нарисуй плиз, какой из 2-х.
V>>Во-первых, не вижу, откуда это следует. S>Это следует из того что реализация предполагает полиморфную рекурсию, тип Queue<a> определен через Queue<Tuple<a,a>>. А С++, как известно, в рантайме порождать типы не умеет.
А зачем порождать? Такие определения расчитаны на языки с зависимыми типами, а они не пользуют информацию о типах в рантайм, т.е. ничего не порождается. Зависимости м/у типами проверяются в compile-time, атем код считается доказанным.
К тому же, берем дотнет, если a и Tuple будут value-type, то будет сгенерированы заново генерик-методы.. а это хана. Я на этой технике когда-то пытался ускорить математические вычисления, где AST, которое можно непосредственно вычислять, строится как похожий динамический тип через вложенные шаблонные определения value-типов... Считает действительно быстро, но уже для вложенности 16 неимоверно долго создает сам тип. А уникальные, т.е. лишь однажды использованные выражения не подбираются затем GC, это же типы, и это дотнет, а не джава...
Я бы предложил для этого алгоритма эмулировать АлгТД, и не порождать ничего в рантайм.
V>>Во-вторых, там вообще работа по несчастным Cons, т.е. организации очереди на односвязанном списке, чтобы время доступа к обоим концам было O(n). Сорри, но я на коленке накатаю очередь, которая порвет эту многократно, и уж конечно будет тоже O(n). S>
S>Theorem 8.3 snoc and tail run in O(1) amortized time.
Да, конечно же O(1), время фиксированное, это я не то написал. Двусвязные списки как раз и нужны для операций на обоих концах за O(1).
S>Я тут не собирался рвать никакие очереди. Я привел пример структуры данных, которая реализуется на генериках и используется в рантайме. Но с удовольствием посмотрю на функциональную (неизменяемую) наколеночную очередь, которая порвет O(1) хотя бы алгоритмически
Ну так когда говорят "порвать многократно", то речь об коэф. при O(x).
V>>Бо мутабельный двусвязанный список всех описанных в той работе приседаний не требует... И там такой разный K при этом O(n) получается, что мама не горюй. Посмотри что происходит при двусторонней выборке. В общем, пусть у функциональщиков будут свои тараканы... S>По-моему ты не разобрался в этой структуре данных. Она рассчитана на двухстороннюю выборку. И даже на логарифмическое обновление в середине.
Справедливости ради, сразу стало ясно, что структуры на immutable-элементах, а их без GC реализовать нереально. Именно поэтому я чуть отошел от конкретного алгоритма и высказался в том плане, что алгоритмы так или иначе надо брать, подходящие для инструмента. Если задача стоит в обычной двухсторонней очереди, то она давно решена для императивных языков.
Насчет навигации в центр за время логарифм — приоритетные очереди в C++ как раз делают через std::map. Берется составной ключ, где одна составляющая приоритет, другая — монотонный номер (напр. тики процессора). В движке для конференций на C# тоже похоже делали, но на упорядоченном массиве (бо средняя длина очереди сообщений была около десятка). Т.е. задача-то известная, как и способы решения.
V>>ИМХО, в основу должны идти не алгоритмы, а требования. А уж алгоритмы берутся те, которые подходящие для инструмента, на котором мы решились эти требования удовлетворить. S>В том что инструмент накладывает ограничения на используемые алгоритмы — я согласен. В том что инструмент является определяющим при выборе алгоритмов — нет.
Является, к сожалению. Пока что очень неудобно разрабатывать проекты так, чтобы был сразу десяток инструментов доступен из-за плясок с сопряжением технологий. Берется один, максимум два инструмента, и приходится затем плясать в выбранных рамках в любой микро-задаче. Удачность выбора — второй вопрос, бо идеальных технологий и серебрянной пули не бывает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но Java все равно на порядок упрощает создание кроссплатформенного софта.
Возможно, но неожиданно решение пришло совсем с другой стороны. Например, мощное железо под юнихами ставят сейчас всё больше для целей виртуализации. Потому что потребность, чтобы работали уже имеющиеся приложения, всяко повыше, потребности обеспечить работоспособность неких будущих.
AVK>Если б качество Моно было чуть получше, кстати, дотнет тоже обеспечивал бы кроссплатформенность лучше даже современного С++.
Опять же возможно... Но только за последние пару лет у нас уменьшилось кол-во бинарно подерживаемых версий gcc (т.е. их соответствующих CRT) примерно вдвое.
Выглядит так, будто дотнет + обновленная джава (предыдущую всерьез не воспринимали) показали кое-какие востребованные фичи от самого понятия "платформы", в итоге компиляторы C++ резко рванули вперед последние лет 5-6.
Смотрю на молодых плюсистов, сходу начинающих пользоваться самыми современными идиомами без проблем (полностью обеспечиваемыми современными компиляторами) и тихо завидую, вспоминая свои убогие в этом плане 90-е... где единственный соответствующий стандартам компилятор генерил самый медленный в истории С++ код. А компилятор MS от 5-ки был притчей во языцах.
Поэтому и рулит PHP, а доля ASP.Net всё еще смехотворна.
