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

ARK>Мда. А доцент-то тупой (с)
главное что ты умен и сообразителен
ARK>Пишут настолько, насколько язык позволяет. Будет позволять больше — будут писать и такие вещи, которые раньше писались на других языках.
Как я выше отметил, в идеальном мире, возможны идеальные языки программирования. Которые позволяют писать идельный код(с точки зрения поддерживаемости, понимания, читабельности, тестируемости) с идеальным перфомансом. Но увы, в реальном мире все немножко не так. Тут внезапно все вышеупомянутые критерии противоречат друг другу, и вопрос в том насколько удачен был выбран компромисс между ними.

I>>Признайся, тебе 20 лет уже исполнилось?
ARK>Что, хорошо на корме рвануло, да?
Ну если саркастичная ухмылка — это рвануло, то ок, считай так

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

lpd>Не берусь ничего по этому вопросу утверждать — я им мало интересовался, т.к. считаю Java/C# тупиковой ветвью CS, а байт код и его оптимизацию не нужными.

1. Самая концепция (про конкретную реализацию не говорим) байт-кода не имеет практически никакого отношения к проблемам Java/C#. Ещё раз предлагаю тебе взглянуть на llvm.

2. Насчёт тупиковой ветви возможно даже соглашусь, но совсем не из-за проблем производительности, а потому что это всего лишь промежуточное решение (между удобством и быстродействием), которое оказалось экономически выгодным в определённый момент времени. Т.е. пошли по пути замены быстродействия простотой программирования, но не дошли до конца по этому пути (как сделали всякие там Python, JS и т.п.), оставшись всего лишь компромиссом. Соответственно гетерогенные решения (где удобные короткие скрипты управляют производительным нативным кодом) будут обходить данное компромиссное решение и по производительности и по простоте разработки. Это сейчас уже видно во многих направлениях и дальше тенденция будет только нарастать. Кстати, это уже давно увидели и в той же MS, так что сменили свой бывший приоритет разработки "всё на .Net" на равномерное (ну это пока) распределение между .Net/C++/JS.

3. Совершенно не поддерживаю твою позицию в стиле "не читал, но осуждаю". ) Критиковать надо исключительно со знанием. И кстати для этого не обязательно писать проекты на Java или C#, но хотя бы знать основополагающие принципы надо. Если уж высказываешься в подобной дискуссии...

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

_>>В то время как в C++ не только часто употребимы не виртуальные функции, но и для виртуальных компилятор гарантированно осуществляет инлайнинг, если они вызваны от обычной переменной (а не от указателя или ссылки).
_>Если под выделенным ты имел ввиду не инлайнинг, а прямой вызов функцуии, то .NEt JIT умеет такое делать.

Я имел в виду как раз инлайнинг, точнее его потенциальную возможность (а осуществлять его или нет компилятор решает сам в зависимости от вида функции — для мелких можно считать гарантированно заинлайнит).

Но даже если говорить про прямой вызов, то как по твоему компилятор C# будет способен это сделать, если там всегда можно написать такой код (где B и C наследники A; а f — виртуальная функция, переопределённая в них):

A a;
if(х) a=new B();
else a=new C();
a.f();

Как по твоему компилятор сможет подставить здесь прямой вызов? )

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

S> Дааааа. Я ведь тебе даю ссылки на инлайнинг, на вызов методов .Net из натива и наоборот. Ты хоть читаешь мои посты?

Я не очень понял твою позицию и есть ли у нас темы для спора. Конкретизирую.

Если ты утверждаешь, что C# код когда-нибудь (при самых идеальных оптимизаторах и т.п.) будет способен догнать по быстродействию код на C++, то тут мы безусловно поспорим, причём ты проиграешь, потому как C# имеет неустранимые дефекты (с точки зрения производительности, но они же могут являться полезностями с других сторон) в самой своей базовой архитектуре.

Если же ты утверждаешь, что C# в данное время развивается в сторону улучшения производительности, то с этим как бы никто и не спорил. Это ясно видно из многих материалов, в том числе и твоих ссылок.

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

_>>В случае C# мы просто имеем отсутствие этих самых библиотек для всех платформ кроме винды.
I>Это не так. Вот тебе: https://www.microsoft.com/net/download/core под винду макось и линукс.

Ну и где там например WPF (это же стандартная библиотека .Net'а, не так ли?)?

_>>На мой взгляд это весьма разный уровень кроссплатформенности. )))
I>На мой взгляд, .NET Core сырой и качество реализации ну просто не фонтан. Я же не ожидал подобных косяков в С++, в котором кроссплатформенность с рождения, более 40 лет.

Ну тут тонкий нюанс в том что стандарт языка тут не соответствует стандарту системы (POSIX) в одной мелочи. А авторы реализации вместо того, чтобы исправить ситуацию (кстати это делается элементарно средствами самого языка, т.е. я элементарно могу написать my_join, который будет работать корректно и на линухе), пошли по лёгкому пути следованию родного (для них) кривого стандарта. Хотя наверное интересно было бы послать им багрепорт и полюбоваться на то, какие отписки там будут. )))

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

EP>>Он плохо оптимизирует в том числе потому что управляемый код труднее оптимизировать. Например замыкания на C++ порождают обычные вызовы, а на C# косвенные.
J>Тут дело не в управляемом коде, а в противопоставлении "шаблоны vs раздельная компиляция". в плюсах, если хоцца отдельно скопилировать ФВП от кода её использущего — тут же скатываешся к std::function и той же самой косвенности вызовов.

Безусловно — если писать на C++ в Java-стиле с кучей индерекций и косвеностей а-ля std::function, то грубо говоря получим аналогичные тормоза.
Но на C++ есть выбор — либо использовать std::function, либо не использовать, причём по-умолчанию второе. На управляемых языках обычно такого выбора нет, только первый вариант

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

ARK>>Хосспади, вы про этот долбаный великолепный .Net Core пишете в каждом посте.
ARK>>Нет его по факту нигде, и не факт, что вообще будет. А если что-то и будет, то по производительности все равно будет хуже, чем С++.
I>Хосспади, вы про эту про эту долбаную производительности числодробилок заманали писать в каждом мосте. Не нужна эта производительность в реальной жизне чуть менее чем никогда. Понимаешь — оно не нужно, даже забесплатно.

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

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

lpd>И без всякой индирекции на одних float'ах, int'ах и массивах получил разницу в 3 раза. Могу поверить, что косвенность вносит свой вклад, но решающий не он.

Решающий вклад в этом коде скорее всего даёт автовекторизация, которую Java не умеет. Отключи в своём C++ примере использование SIMD инструкций и увидишь разницу. ) Хотя конечно же в Java есть и свои врождённые тормоза, проявляющиеся в этом пример, типа проверки границ массива и т.п. Но в данном случае они вряд ли главные. )))

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

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

lpd>>И без всякой индирекции на одних float'ах, int'ах и массивах получил разницу в 3 раза. Могу поверить, что косвенность вносит свой вклад, но решающий не он.

_>Решающий вклад в этом коде скорее всего даёт автовекторизация, которую Java не умеет. Отключи в своём C++ примере использование SIMD инструкций и увидишь разницу. ) Хотя конечно же в Java есть и свои врождённые тормоза, проявляющиеся в этом пример, типа проверки границ массива и т.п. Но в данном случае они вряд ли главные. )))

Да, в данном случае без автовекторизации С++ стал исполняться существенно медленнее.

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

ARK>>Даже для C# нужна скорость, например для того, чтобы писать игры. Больше скорость — больше возможностей. Это как, доступно для понимания, или не совсем?
I>Как уже мы выяснили в соседнем треде, скорей всего ты молод, а поэтому воинствующая глупость скорей всего может быть обьяснена недостатком опыта, образования, гормонами.. в общем как и у всех в молодости

Да нет, это как раз с вашей стороны воинствующая (ну и не только) глупость. Плюс ничем не обоснованное высокомерие и постоянные переходы на личности.

Да еще и "выяснили" что-то, я и не заметил.

I>Ну дык от, с учетом всего вышесказанного, разжую, как мне разжевывали.

Опять высокомерие.

I>Максимальный перфоманс может быть достигнут только в новых схемотехнических решениях. И за доказательствами ходить далеко не нужно, интегрированные процы на геймерских видеокартах на специфических задачах рвут i7 как тузик грелку. И любой дальнейший отход от схемотенических решений, как то: программирование в двоичных кодах, ассембелер, с, с++, управляемых языках — это сознательная жертва производительности в угоду другим критериям. Таким как: универсальность, скорость разработки, цена мейтененса, тестируемость и так далее. И на каждом этапе возникал вопрос о балансе: а не много ли мы перфоманса пожертвовали для того чтобы миллион тупых славян индусов смогли выдавать предсказуемый результат? И в случае с C# ответ очевиден: среда разработки, изначально таргетированная на рынок бизнес приложений внезапно стала востребованной и на рынке игр. Потому что перфоманса достаточно!

Да уж, разжевал так разжевал. Ну а по сути это просто личное мнение, не имееющее отношения к реальности. Никакого "баланса" в играх нет, их как писали на С/С++, так и пишут. Не так давно стали ограниченно применять C#, ограниченно — по причине его тормознутости для данной области. Будет нативная компиляция, будет больше скорость — будет больше применений. Так что жуйте дальше.

ARK>>А новый компилятор — это не новое? Забавно.
I>Выход новой версии gcc — это канечна да, новый этап, знаменующий собой тотальный прогресс в С++7 пойду пацанам расскажу, посмеемся вместе

NET Native — это новая версия старого управляемого компилятора?

ARK>>Хм, ну и что я там должен увидеть?
ARK>>Вот это?
ARK>>

The main point is to enable "native compilation" (so you don't need .NET framework/VM installed on the target machine.

ARK>>Ну, это довольно очевидно...
I>Перечитай пока не дойдет.

По-моему, это вполне смежные вещи, нативная компиляция и скорость. Впрочем, если кор делается ради "модульности", то это еще тупее, чем я думал.

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

Очередное обсуждение моей личности, да вы просто в ударе. Вы вот моим возрастом интересуетесь, а вам самому-то сколько лет, дорогой друг, если не секрет?

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

ARK>>Пишут настолько, насколько язык позволяет. Будет позволять больше — будут писать и такие вещи, которые раньше писались на других языках.
I>Как я выше отметил, в идеальном мире, возможны идеальные языки программирования. Которые позволяют писать идельный код(с точки зрения поддерживаемости, понимания, читабельности, тестируемости) с идеальным перфомансом. Но увы, в реальном мире все немножко не так. Тут внезапно все вышеупомянутые критерии противоречат друг другу, и вопрос в том насколько удачен был выбран компромисс между ними.

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

I>>>Признайся, тебе 20 лет уже исполнилось?
ARK>>Что, хорошо на корме рвануло, да?
I>Ну если саркастичная ухмылка — это рвануло, то ок, считай так

Ухмылки не заметил, но заметил, что вы просто постоянно переводите разговор с темы на мою личность. Это выдает признаки начавшегося кормового пожара.

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

_>3. Совершенно не поддерживаю твою позицию в стиле "не читал, но осуждаю". ) Критиковать надо исключительно со знанием. И кстати для этого не обязательно писать проекты на Java или C#, но хотя бы знать основополагающие принципы надо. Если уж высказываешься в подобной дискуссии...

Оптимизацией на уровне компилятора я, действительно, мало интересовался, и обычно стараюсь оптимизировать, прежде всего, алгоритм. Однако на Java я насмотрелся прежде всего как пользователь тормозного Android'а(да и программировать под него доводилось). Последние модели вроде работают, впрочем, побыстрее. Но мне кажется идея создания промежуточного кода избыточной. Возможно, что это вопрос вкуса, однако в IT простые инструменты нередко выигрывают у сложных(unix) и монструзоных(Windows и .NET). Все же C#/Java как языки програмирования немного получают за счет потерь производительности. Впрочем, я не хочу начинать этот спор сначала, а просто подытожил свое мнение, т.к. дискусия ушла от обсуждения следствий низкой скорости C#/Java к ее причинам.

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

_>Ну и где там например WPF (это же стандартная библиотека .Net'а, не так ли?)?

Нет, WPF в .NET Standard 1.6 не входит.

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

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

S>> Дааааа. Я ведь тебе даю ссылки на инлайнинг, на вызов методов .Net из натива и наоборот. Ты хоть читаешь мои посты?

_>Я не очень понял твою позицию и есть ли у нас темы для спора. Конкретизирую.

_>Если ты утверждаешь, что C# код когда-нибудь (при самых идеальных оптимизаторах и т.п.) будет способен догнать по быстродействию код на C++, то тут мы безусловно поспорим, причём ты проиграешь, потому как C# имеет неустранимые дефекты (с точки зрения производительности, но они же могут являться полезностями с других сторон) в самой своей базовой архитектуре.

Давай рассмотрим нынешние дефекты
1. Для сборщика мусора нужно подготавливать точки для остановки потока для сборки мусора
2. Выделение памяти для объектов на стеке и автоматический финализатор для них. В этом направлении сейчас ведутся работы
3. Работа напрямую с нативной памятью. Тоже ведутся работы.
4. Нет инлайнинга для делегатов,интерфейсов там где можно вывести код на стадии компиляции, но и здесь ведутся работы пример Roslin Linq
5. Net Native сейчас только на начальном пути развития, но уже сейчас может оптимизировать компиляцию Il кода используя компилятор С++


_>Если же ты утверждаешь, что C# в данное время развивается в сторону улучшения производительности, то с этим как бы никто и не спорил. Это ясно видно из многих материалов, в том числе и твоих ссылок.

Ну я просто считаю, что у С++ просто уменьшится доля, там где скорость будет достаточно близка.

Только это будет не скоро. А к тому времени, может и С++ будет совсем иным.

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

S>И ты тудаже.

Я оттуда же и не возвращался еще.

Весь код по ссылке именно таков как раз от того, что дотнетный якобы "параметрический полиморфизм" не в состоянии разресолвится статически, исключив динамику интерфейсных вызовов, потому что не реализует статически даже полиморфизм 1-го ранга, в отличие от того же Хаскеля, который ровно в этих же сценариях ресолвит всё статически.

S>По приведенной ссылке прежде много кода генерится всего из за того, что код не инлайнится.

А вот ты именно что "туда даже" в пытках облегчить себе задачу, прилюдно допустив, что оппонент нифига не понимает.
Тот код по ссылке в том числе избавляет и от copy&paste.


S>Я привел тебе ссылки где методы инлайнятся и нет разницы между value и ref типами

Мне приводили много разного кода. В них было разное:
— ad hoc полиморфизм на лямбде, хотя спор идёт о параметрическом полиморфизме (дополнительно я делаю замечание о том, что код лямбды — это copy&paste, ты же мужественно делаешь вид "ну и что?"... мужик, мужик... так закалялась сталь! ))
— параметрический полиморфизм, не способный разресолвится статически, т.е. работающий через метод интерфейса.

Ну и, я и сам смогу тебе привести сходу пример, где такой полиморфизм сможет разресолвится статически в дотнете, я уже озвучивал — это при использовании технологии "объекта-словаря операций" (и в приводимых к этой концепции сценариях), где сам такой объект представлен value-типом. Ну не популярная эта техника нифига в дотнете. Там никто не таскает в логике эти словари рядом с целевыми объектами, везде идёт попытка работать с объектами напрямую. А когда напрямую, то возвращаемся к самому первому моему утверждению:

Собсно, вообще таких алгоритмов мало, которые можно выразить в дотнете для value и ref-типов в генериках и они будут корректно работать в обоих случаях.

Потому что получается так, что лишь теми операциями, которыми обложили базу объекта (интефейс интерфейса или публичный интерфейс базового класса) и можно оперировать. И шаг вправо-влево сделать вааще никак.

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


S> А что же это такое? Лямбда, замыкание, который может захватывать и внутренние переменные например
S>var f=5;
S>.Where(x => x > q+f).Select(x => x + f).Sum();

Сорри, но рука, таки, добежала до лица.
Ты зачем ввёл f? У тебя там уже был q ровно в этой же роли.

Как сам считаешь, я ждал подобного примера, или нет?
Я ждал тыкания в меня переменной q. Кароч, ты даже превзошёл мои ожидания. ))

У меня уже был заготовлен тот ответ, что захват контекста "by name" и "by value" — это принципиально различные вещи. Когда мы захватываем контекст by value, т.е. специализируем аргумент(ы) некую ф-ию константой(ами)/значением(ями), то для таких вещей достаточно техники частичной специализации. Ну да, её нет в явном виде в C#, поэтому везде идёт лямбда. ))


S>Еще раз посмотри как эти лямбды разворачиваются

Зачем? Думаешь, с первого раза не дошло?
Или, думаешь, что можно запросто игнорить уже данный на это ответ:

Это всё к тому, что твой пример с copy&paste вот этого:
...
в общем случае является плохой практикой.
Но язык позволяет только такую.

V>>Т.е., речь о том, что неуникальный случай в C# описать не так-то просто (тем паче с должной эффективностью).

И вот тут ты не ответил. А ведь это был ответ на тот вопрос, который ты пытаешься повторять уже, еще не "отстрелявшись" с должной убедительностью по уже данным моим замечаниям.


V>>Не можешь. В теле дотнетной лямбды происходит автовывод типов, поэтому ты вызываешь методы конкретных типов. А для реализации предиката в виде генерика исходные типы должны поддерживать некие данные ЗАРАНЕЕ ограничения на шаблонах или использовать т.н. "объекты-словари операций", навроде IComparer<T>, который в свою очередь может оперировать лишь типами, над которыми ПРЕДВАРИТЕЛЬНО заданы некие ограничения в виде опять и снова интерфейсов.
S>И что мне мешает объявить метод?

Ничего. "Объекты-словари операций" — отличная техника.
(Ты хоть понимаешь, о какой технике речь? А то, может, я с тем же успехом мог с Космосом разговаривать всё это время)

Но что мешает использовать эту технику повсеместно в дотнете, Ы?
Может, то, что в концепции дотнетного ООП такая техника выглядит заимствованием из чужеродного ФП?
Т.е., те фишки ФП, которые не руинят ООП — они в практику дотнета таскаются с удовольствием, смотрю. Остальные практики игнорятся, хотя именно такая реализация параметрического полиморфизма требует именно таких практик. ))


V>>Конечно удобны. Но я на это тоже уже отвечал заранее:
V>>

V>>Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.

V>>С++ позволяет комбинировать технику шаблонов и лямбд, используя каждую из техник по прямому назначению, т.е. заставляя их выполнять исключительно "свою" часть работы.
S>Это же все можно делать и на C#

Можно, но сложнее, чем в С++ и это, блин, очевиднее ж некуда. Т.е. меня во всём этом споре удивляет такая высокая мотивированность оппонентов спорить с очевидным. Понятно же, что в тех случаях, где код в С++ можно продолжать оформлять в концепции ООП и всё еще получать инлайнинг и тру-статический ресолвинг параметрического полиморфизма, в дотнете уже требуется аналогичный код переводить в хардкорный ФП, резко повышая тот самый "порог вхождения" бедного дотнетного программиста. ))

Ну или подменять генерики на лямбды, т.е. параметрический на ad hoc полиморфизм, но это уже сразу вылет за границы обсуждаемого и желтая карточка оппоненту. Лично ты этих желтых карточек набрал уже — у-у-у-у )))

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

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

S>>И ты тудаже.

V>Я оттуда же и не возвращался еще.
V>

V>Весь код по ссылке именно таков как раз от того, что дотнетный якобы "параметрический полиморфизм" не в состоянии разресолвится статически, исключив динамику интерфейсных вызовов, потому что не реализует статически даже полиморфизм 1-го ранга, в отличие от того же Хаскеля, который ровно в этих же сценариях ресолвит всё статически.

S>>По приведенной ссылке прежде много кода генерится всего из за того, что код не инлайнится.

V>А вот ты именно что "туда даже" в пытках облегчить себе задачу, прилюдно допустив, что оппонент нифига не понимает.
V>Тот код по ссылке в том числе избавляет и от copy&paste.

Я к тому же, что этот пример приводит постоянно один человек, и считает это доказательством дефекта .Net. Это как про Каррузо, которого Моня напел.

S>>Я привел тебе ссылки где методы инлайнятся и нет разницы между value и ref типами

V>Мне приводили много разного кода. В них было разное:
V>- ad hoc полиморфизм на лямбде, хотя спор идёт о параметрическом полиморфизме (дополнительно я делаю замечание о том, что код лямбды — это copy&paste, ты же мужественно делаешь вид "ну и что?"... мужик, мужик... так закалялась сталь! ))
V>- параметрический полиморфизм, не способный разресолвится статически, т.е. работающий через метод интерфейса.

Какя лямбда копи пасте? Для Where и Select по сути нет одинаковых методов, но если они нужны я могу where заменить на специализированную функцию. Нет проблем.
Linq to EF. Практика использования. Часть III


V>Ну и, я и сам смогу тебе привести сходу пример, где такой полиморфизм сможет разресолвится статически в дотнете, я уже озвучивал — это при использовании технологии "объекта-словаря операций" (и в приводимых к этой концепции сценариях), где сам такой объект представлен value-типом. Ну не популярная эта техника нифига в дотнете. Там никто не таскает в логике эти словари рядом с целевыми объектами, везде идёт попытка работать с объектами напрямую. А когда напрямую, то возвращаемся к самому первому моему утверждению:
V>

V>Собсно, вообще таких алгоритмов мало, которые можно выразить в дотнете для value и ref-типов в генериках и они будут корректно работать в обоих случаях.

V>Потому что получается так, что лишь теми операциями, которыми обложили базу объекта (интефейс интерфейса или публичный интерфейс базового класса) и можно оперировать. И шаг вправо-влево сделать вааще никак.

Угу все коллекции, словари прекрасно работатют и с теми и другими типами.

V>Но спорить с подобными утверждениями тоже надо уметь. Пытаясь мне показать, что такие алгоритмы все-таки есть, вы показываете банальное невладение логикой. ))


S>> А что же это такое? Лямбда, замыкание, который может захватывать и внутренние переменные например
S>>var f=5;
S>>.Where(x => x > q+f).Select(x => x + f).Sum();

V>Сорри, но рука, таки, добежала до лица.
V>Ты зачем ввёл f? У тебя там уже был q ровно в этой же роли.

Затем, что бы дать понять, что это замыкание.

V>Как сам считаешь, я ждал подобного примера, или нет?
V>Я ждал тыкания в меня переменной q. Кароч, ты даже превзошёл мои ожидания. ))

Согласен, q просмотрел. Прошу прощения.
V>У меня уже был заготовлен тот ответ, что захват контекста "by name" и "by value" — это принципиально различные вещи. Когда мы захватываем контекст by value, т.е. специализируем аргумент(ы) некую ф-ию константой(ами)/значением(ями), то для таких вещей достаточно техники частичной специализации. Ну да, её нет в явном виде в C#, поэтому везде идёт лямбда. ))

Еще раз по своей сути лямбда мало отличается от C++ лямбды. Её так же можно развернуть в инлайн код.
Просто это только сейчас начинается.


S>>Еще раз посмотри как эти лямбды разворачиваются

V>Зачем? Думаешь, с первого раза не дошло?
V>Или, думаешь, что можно запросто игнорить уже данный на это ответ:
V>

V>Это всё к тому, что твой пример с copy&paste вот этого:
V>...
V>в общем случае является плохой практикой.
V>Но язык позволяет только такую.

Ты хоть объясни про copy&paste. Нет у меня одинаковых Where а там где есть, я могу либо заменить Where на свою спец функцию, либо добавить любой метод Func(T,bool)

V>>>Т.е., речь о том, что неуникальный случай в C# описать не так-то просто (тем паче с должной эффективностью).
Еще раз работы в этом направлении ведутся.

V>И вот тут ты не ответил. А ведь это был ответ на тот вопрос, который ты пытаешься повторять уже, еще не "отстрелявшись" с должной убедительностью по уже данным моим замечаниям.


V>>>Не можешь. В теле дотнетной лямбды происходит автовывод типов, поэтому ты вызываешь методы конкретных типов. А для реализации предиката в виде генерика исходные типы должны поддерживать некие данные ЗАРАНЕЕ ограничения на шаблонах или использовать т.н. "объекты-словари операций", навроде IComparer<T>, который в свою очередь может оперировать лишь типами, над которыми ПРЕДВАРИТЕЛЬНО заданы некие ограничения в виде опять и снова интерфейсов.

Так ограничения это хорошо. Мы сразу видим какие методы поддерживаются при создании дженерик класса. Но при этом мы можем и проинлайнить этот метод при специализации.
S>>И что мне мешает объявить метод?


V>Ничего. "Объекты-словари операций" — отличная техника.
V>(Ты хоть понимаешь, о какой технике речь? А то, может, я с тем же успехом мог с Космосом разговаривать всё это время)

Еще раз я говорю о том, что уже сейчас ограничения можно и инлайнить.
V>Но что мешает использовать эту технику повсеместно в дотнете, Ы?
V>Может, то, что в концепции дотнетного ООП такая техника выглядит заимствованием из чужеродного ФП?
V>Т.е., те фишки ФП, которые не руинят ООП — они в практику дотнета таскаются с удовольствием, смотрю. Остальные практики игнорятся, хотя именно такая реализация параметрического полиморфизма требует именно таких практик. ))

Делают делают. Но неспешно.

V>>>Конечно удобны. Но я на это тоже уже отвечал заранее:
V>>>

V>>>Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.

На самом то деле как правило ограничения не большие. Ну и никто не мешает тебе вывести в отдельную функцию. В чем проблема я не вижу.


V>>>С++ позволяет комбинировать технику шаблонов и лямбд, используя каждую из техник по прямому назначению, т.е. заставляя их выполнять исключительно "свою" часть работы.
S>>Это же все можно делать и на C#

V>Можно, но сложнее, чем в С++ и это, блин, очевиднее ж некуда. Т.е. меня во всём этом споре удивляет такая высокая мотивированность оппонентов спорить с очевидным. Понятно же, что в тех случаях, где код в С++ можно продолжать оформлять в концепции ООП и всё еще получать инлайнинг и тру-статический ресолвинг параметрического полиморфизма, в дотнете уже требуется аналогичный код переводить в хардкорный ФП, резко повышая тот самый "порог вхождения" бедного дотнетного программиста. ))

Наоборот легче. Так ка я на стадии кодирования дженерик метода получаю и интелиссенсе и проверку. А вот компиляторо на этапе в компиляции в IL может так же инлайнить при специализации .


V>Ну или подменять генерики на лямбды, т.е. параметрический на ad hoc полиморфизм, но это уже сразу вылет за границы обсуждаемого и желтая карточка оппоненту. Лично ты этих желтых карточек набрал уже — у-у-у-у )))

Ну да лучше писать и надеяться что есть перегрузка оператора без интелиссенсе и искать ошибки при специализации шаблона.
ууууу

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

EP>Не проходи мимо, загляни в форум .NET, пройдись например по первым десяти темам и посчитай в скольких из них "не нужна производительность, даже забесплатно"
Заглянул

Какой из них про перфоманс?

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

ARK>Опять высокомерие.
это снисходительность

ARK>Да уж, разжевал так разжевал. Ну а по сути это просто личное мнение, не имееющее отношения к реальности. Никакого "баланса" в играх нет, их как писали на С/С++, так и пишут. Не так давно стали ограниченно применять C#, ограниченно — по причине его тормознутости для данной области. Будет нативная компиляция, будет больше скорость — будет больше применений. Так что жуйте дальше.
Сколько лет Unity? Xamarin? Из старичков могу вспомнить космических рейнджеров, написанных (в основном) на делфи. А серверная часть современных сетевых игрух сплошь и рядом на java &.NET. Но ты продолжай верить, чо уж.
Ну и главное — кроме игр будут примеры?

ARK>NET Native — это новая версия старого управляемого компилятора?
Именно. Раньше можно было запустить прекомпиляцию на конечной машине, сейчас — на серваке перед скачиванием апликухи. Ничего революционного.

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


ARK>Ну, хватит юлить уже. Идеальный мир, компромисс... Сейчас для определенных применений C# просто закрыт.
Я тебе даже больше скажу — его разрабатывали для решения ограниченного круга задач. И он оказался настолько удачным, что круг решаемых задач постоянно расширяется. Но я стобой полностью согласен — универсальной помойкой аля С++ он наврядли когда нибудь станет.

ARK>Ухмылки не заметил, но заметил, что вы просто постоянно переводите разговор с темы на мою личность. Это выдает признаки начавшегося кормового пожара.
Не, просто интересно — угадал возраст по постам или нет. Ничо более.

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


ARK>>NET Native — это новая версия старого управляемого компилятора?
I>Именно. Раньше можно было запустить прекомпиляцию на конечной машине, сейчас — на серваке перед скачиванием апликухи. Ничего революционного.

https://msdn.microsoft.com/ru-ru/library/dn807190(v=vs.110).aspx

.NET Native и NGEN


Генератор образов в машинном коде (NGEN) компилирует сборки в машинный код и устанавливает их в кэш образов в машинном коде на локальном компьютере. Однако хотя NGEN, как и .NET Native, создает машинный код, NGEN имеет существенные отличия от .NET Native:
Если для конкретного метода нет образа в машинном коде, NGEN переключается на JIT-компиляцию кода. Это означает, что образы в машинном коде должны продолжать включать метаданные и IL-код для того случая, если генератору NGEN необходимо переключиться на JIT-компиляцию. В противоположность этому .NET Native только создает образы в машинном коде и не переключается на JIT-компиляцию. В результате должны сохраняться метаданные, необходимые только для некоторых сценариев отражения, сериализации и взаимодействия.
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
Образы NGEN, как правило, хрупкие. Например, обновление или изменение зависимости обычно требует, чтобы сборки, которые его используют, также были пересозданы NGEN. Это особенно верно для системных сборок в библиотеке классов .NET Framework. В противоположность этому .NET Native позволяет обслуживать приложения независимо друг от друга.